数据库查询慢的原因

1、数据库查询慢的原因一般关系型数据库的物理存储分为堆和B+树，一般索引的存储结构为 B+树，而数据表如果没有建立聚集索引的话，数据就是堆存储。这两 种存储结构会很大程度上印象查询效率，B+树可以按照Key进行定向 查找，而堆只能逐行扫描。这就像去图书馆找一本书，通过索引号可以 快速找到其位置，而从书架上一排排看过去效率就很低。这里需要说明一下，并非B+树的存储结构永远比堆存储结构好，至于 什么情况下适合用堆存储，大家可以讨论一下。查找效率低我们知道非聚集索引只是存储了索引本身包含的字段以及聚集索引的 字段（如果有的话），所以如果按照非聚集索引查找，很可能还需要二 次查找，也就是非聚集索引只是提供

2、了数据的实际存储地址，还需要额 外的磁盘IO去实际存储地址查找，这就会在一定程度上影响查询性能。查找效率还会受列存储和行存储的影响，列存储是按照表格中的同一列 数据一起存储，而行存储是把表格中的数据一行一行的一起存储，这两 种存储方式也会对查找效率造成影响。磁& IO过高一般查询引擎都是按照数据块读取，只要某个数据块中有需要的数据， 那么就会把这个数据块读取到内存中，所以如果数据过于分散，也会很 大程度上影响查询效率，表现为磁盘IO很高。这方面涉及到索引碎片， 索引重建，索引整理等技术。另外数据的压缩比也会影响到磁盘的IO，理论上压缩比越高，数据读 取的效率越高，相同情况下磁盘IO会低很多，但

3、是数据压缩意味着存 储时需要压缩，读取后需要解压，所以需要综合考虑，并非压缩比越高 越好。查询等待时间过长有时候分析查询过程会发现，执行耗时很短，反而大部分时间都在排队， 这种现象在多产品共用一个查询平台时最容易出现（请允许我先哭上三 分钟.），导致这种情况一般是系统资源不足（内存不足等），导致 无法为查询分配足够的资源执行。查询等待还经常会因为锁等待导致，也就是当我想查这行数据时，其他 人正在对这行数据进行编辑（排它锁），这时候我就需要等对方编辑完 成才能读取。这方面根据实际场景可以考虑脏读等方式。网络传输原因数据在服务器端查询完成之后一般都需要通过网络传输到客户端，这时 候如果一次返回的数

4、据量过大，也会导致用户感觉查询变慢，这种情况 需要应用端进行分页处理，或者对数据进行压缩传输。执行计划不合理因为索弓I碎片过大或者统计信息缺失等原因会造成数据库的查询引擎 生成一些不够合理的查询计划，这时候推荐的做法是重建索引或者更新 统计信息，当然也可以使用hint的方式强制更改查询计划，但这种方 式很容易遗忘，引发后续其他情况下的查询问题。系统资源不足或者被抢占现在一般服务器都是采用虚拟化的技术进行资源隔离，但是很多虚拟化 技术无法控制CPU的隔离，所以如果其他应用占用了大量CPU资源可 能会导致数据库查询慢。数据库的查询操作一般都现在内存中查找是否缓存了相应数据，如果没 有则需要先把数据读取到内存中，这就导致了，当内存过低时，会造成 查询命中率很低，需要频繁的到磁盘中读取数据，从而影响数据库的查 询性能。数据库是高内存，高IO，高CPU的应用，所以一般推荐一个物理机上 不要开多个数据库服务器，避免相互抢占资源。硬件配置不足上面提到，数据库是高内存，高IO，高CPU的应用，