五个优化SQL语句性能的小窍门 进一步优化查问性能

在启动数据库操作时，优化SQL语句是优化性能和效率的关键步骤之一。无论是处置大规模数据还是便捷的查问，优化SQL语句都可以显著改善系统的照应期间和资源应用率。

本文引见五个适用的优化SQL的技巧，协助读者更好地利用索引、防止性能瓶颈，并提高数据库的全体性能。

1 内衔接说明

当触及到多个表的衔接查问时，通经常常使用join关键字。

最罕用的衔接模式是左衔接和内衔接。

以下是经常使用inner join的示例：

 oidocodeuname  o   u  ouser_id  uid u

假设两个表经常使用inner join关联，MySQL会智能选用两个表中的小表驱动大表，因此在性能上不会产生太多疑问。

以下是经常使用left join的示例：

 oidocodeuname  o   u  ouser_id  uid u

假设两个表经常使用left join关联，MySQL自动经常使用左衔接关键字驱动右侧的表。假设左表中存在少量数据，则或许会产生性能疑问。

须要留意的是，在经常使用left join查问时，应该将小表放在左侧，将大表放在右侧。假设可以经常使用inner join，应尽量防止经常使用left join。

2 限度索引的数量

妇孺皆知，索引可以大幅提高SQL查问的性能，但索引的数量并不是越多越好。

由于当向表中减少新数据时，同时须要为其创立索引，而索引须要额外的存储空间和必定的性能消耗。

单个表中的索引数量应尽量控制在5个以内，单个索引中的字段数量也不应超越5个。

MySQL经常使用的B+树结构来保留索引，B+树索引在拔出、更新和删除操作时须要启动更新。假设索引过多，将消耗少量的额外性能。

那么，假设表中的索引过多，超越了5个怎样办呢？

这个疑问须要辩证地看待。假设你的系统并发性较低，表中的数据量也不是很大，实践上可以经常使用超越5个的索引，只需不适度即可。

但关于一些高并发的系统，务必遵守单个表上不超越5个索引的限度。

那么，高并发系统如何优化索引的数量呢？

假设可以建设联结索引，就不要建设单个索引，可以删除一些无用的单个索引。

将一些查问配置迁徙到其余类型的数据库中，比如Elastic Seach、HBase等，只需在业务表中建设大批的关键索引即可。

3 选用适当的字段类型

char示意固定长度的字符串类型，该类型的字段存储空间是固定的，会糜费存储空间。

varchar示意可变长度的字符串类型，该类型的字段存储空间会依据实践数据的长度启动调整，不会糜费存储空间。

假设是固定长度的字段，比如用户的手机号码，普通是11位，可以定义为长度为11字节的char类型。

但假设是企业称号字段，假设定义为char类型，会存在疑问。

假设长度定义得过长，例如定义为200字节，而实践企业称号只要50字节，将糜费150字节的存储空间。

假设长度定义得过短，例如定义为50字节，而实践企业称号有100字节，将不可存储，并抛出意外。

因此，倡导将企业称号改为varchar类型。可变长度字段的存储空间较小，可以节俭存储空间，关于查问来说，在相对较小的字段中搜查效率显然更高。

选用字段类型时，应遵照以下准则：

假设可以经常使用数字类型，就不要经常使用字符串，由于数字类型的存储空间更小，查问效率更高。

尽量经常使用小型类型，例如经常使用bit类型存储布尔值，tinyint类型存储枚举值等。

关于固定长度的字段，可以经常使用char类型。

关于可变长度的字段，可以经常使用varchar类型。

关于金额字段，经常使用decimal类型，防止精度失落的疑问。

4 提高group by的效率

在许多业务场景中，须要经常使用group by关键字。它的关键配置是启动去重和分组。

通常，与having一同经常使用，示意依照某些条件启动分组，而后再过滤数据。

失误示例

 user_iduser_name    user_id user_id  

这种写法性能较差。它首先依据用户ID对一切订单启动分组，而后挑选出用户ID大于或等于200的用户。

分组是一个相对耗时的操作，为什么不在分组之前减少数据范围呢？

正确示例

 user_iduser_name   user_id    user_id

经常使用where条件在分组之前过滤掉冗余数据，这样在分组时效率会更高。

实践上，这是一个思绪，不只仅适用于group by的优化。在SQL语句口头一些耗时操作之前，应尽量减少数据范围，这样可以提高全体SQL的性能。

5 索引优化

在SQL优化中，索引优化是十分关键的内容。

在许多状况下，经常使用索引和不经常使用索引时，SQL语句的口头效率会有很大差异。因此，索引优化是SQL优化的首选。

索引优化的第一步是审核SQL语句能否曾经经常使用了索引。

那么，如何审核SQL能否经常使用了索引呢？

可以经常使用explain命令检查MySQL的口头方案。

以下是索引失效的一些经常出现要素：

假设不是由于上述要素，就须要进一步伐查其余要素。

此外，您能否曾经遇到过这样的状况：明明是相反的SQL，只是输入参数不同。有时刻索引a失效，有时刻索引b失效？

有时刻MySQL会选用失误的索引。

假设有必要，可以经常使用force index来强迫查问SQL经常使用特定的索引。