怎么提高数据库查询效率

提高查询效率首先要想到的就是加索引，那什么是索引呢？

MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。

打个比方，如果合理的设计且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。

索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索引包含多个列。

创建索引时，你需要确保该索引是应用在 SQL 查询语句的条件(一般作为 WHERE 子句的条件)。

实际上，索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录。

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。

建立索引会占用磁盘空间的索引文件。

如何使用索引呢？

首先索引有窄索引和宽索引两个概念，窄索引是指索引的列数为1~2，宽索引就是说索引的列数大于2。

因为窄索引的效率要高于宽索引，所以能用窄索引就不要使用宽索引。

那么对单字段索引和复合索引应该如何使用？

目录

单字段索引的情况：

复合索引的优势：

两者的比较：

单字段索引的情况：

1.表的主键，外键必须有索引

2.数据量超过300的表应该有索引

3.经常与其他表进行连接的表，在连接字段上应该建立索引

4.经常出现在where字句中的字段，特点是大表的字段，应该建立索引

5.索引应该建在选择性高的字段上

6.索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建立索引

7.尽量用单字段索引代替复合索引，复合索引的建立需要仔细的斟酌

复合索引的优势：

1.单字段索引很少甚至没有

2.复合索引的几个字段经常同时以AND的方式出现在where语句

当where语句中的条件是OR时，索引不起作用。

两者的比较：

以一个sql语句来举例：SELECT * FROM STUDENT WHERE SEX="男" AND SAGE=18

若在sex 和 sage 两个字段分别创建了单字段索引，mysql查询每次只能使用一个索引，虽然对于未添加索引时使用全盘扫描,我们的效率提升了很多，但如果在sex 和 sage两个字段添加复合索引，效率会跟高，如： 创建(sex, age,teacher)的复合索引，那么其实相当于创建了(area,age,teacher)、(area,age)、(area)三个索引，这被称为最佳左前缀特性。

那对于两者优缺点的比较：

1.对于具有2个用and连接条件的语句，且2个列之间的关联度较低的情况下，复合索引有一定优势。

2.对于具有2个用and连接条件的语句，且2个列之间的关联度较高的情况下，复合索引有很大优势。

3.对于具有2个用or连接条件的语句，单索引有一定优势，因为这种情况下复合索引将会导致全表扫描，而前者可以用到indexmerge的优化。

以上就是如何提高查询效率的全部内容，如果有帮助到你的话记得点个关注哟

我以前收藏的，挺不错：

1、存储

将硬盘分成NTFS格式，NTFS比FAT32快，并看你的数据文件大小，1G以上你可以采用多数据库文件，这样可以将存取负载分散到多个物理硬盘或磁盘阵列上。

2、tempdb

tempdb也应该被单独的物理硬盘或磁盘阵列上,建议放在RAID 0上，这样它的性能最高,不要对它设置最大值让它自动增长

3、日志文件

日志文件也应该和数据文件分开在不同的理硬盘或磁盘阵列上，这样也可以提高硬盘I/O性能。

4、分区视图

就是将你的数据水平分割在集群服务器上，它适合大规模OLTP,SQL群集上，如果你数据库不是访问特别大不建议使用。

5、簇索引

你的表一定有个簇索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。

6、非簇索引

非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。

7、索引视图

如果在视图上建立索引,那视图的结果集就会被存储起来，对与特定的查询性能可以提高很多，但同样对update语句时它也会严重减低性能，一般用在数据相对稳定的数据仓库中。

8、维护索引

你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。

不论你是用几个表1、2、3点都可以提高一定的性能，5、6、8点你是必须做的，至于4、7点看你的需求。

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看，很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要象普通由CLIENT提交的SQL那样进行处理和编译。8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了获取少量字段而写SELECT * 对性能的损害也比较利害。9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。10、评估你开发系统的关键业务，在很多数据库系统对性能的要求是彼此矛盾的，比如OLTP应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度，而大量的索引对OLTP则是负担。11、不要在应用程序中写怪异的SQL 查询，比如 WHERE money!40000，这样的语句，这种SQL查询，数据库的SQL优化器是无法进行优化的。12、定期维护和管理你的数据库系统，压缩掉那些垃圾空间，很多数据库系统执行类似删除，事务等 *** 作的时候，并不回收无用的物理空间。所以，制定一份合理的数据库维护计划，不要等日志文件或者LOG文件越长越大的时候才去整理数据库。还有很多很多要注意的东西，。。。。。。

---