MYSQL查询优化（二）

梦里梦外; 2021-09-10 15:04 334阅读 0赞

1、优化数据类型

（1）避免使用NULL

NULL对于大多数数据库都需要特殊处理，MySQL也不例外，它需要更多的代码，更多的检查和特殊的索引逻辑，有些开发人员完全没有意识到，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0、-1作为默认值。

（2）仅可能使用更小的字段

MySQL从磁盘读取数据后是存储到内存中的，然后使用cpu周期和磁盘I/O读取它，这意味着越小的数据类型占用的空间越小，从磁盘读或打包到内存的效率都更好，但也不要太过执着减小数据类型，要是以后应用程序发生什么变化就没有空间了。修改表将需要重构，间接地可能引起代码的改变，这是很头疼的问题，因此需要找到一个平衡点。

2、小心字符集转换

客户端或应用程序使用的字符集可能和表本身的字符集不一样，这需要MySQL在运行过程中隐含地进行转换，此外，要确定字符集如UTF-8是否支持多字节字符，因此它们需要更多的存储空间。

3、优化count(my\_col)和count(\*)

如果你使用MyISAM表，在没有where子句的情况下使用count(\*)速度是很快的，因为行数量的统计是非常精确的，因此MySQL不会一行一行地去找，进而得出行数，如my\_col列没有空值，那么和前面说的情况会一样，即count(my\_col) 速度也会很快。

如果有where子句时使用count()，基本上就无法进行更多优化了，在where子句中超出了明显的索引列，对于复杂的where子句，只有使用覆盖索引才有用。

除了上面的建议外，你还可以使用汇总表，它们让你可以对表的内容保持更新，你可以使用触发器，或者应用程序逻辑保持汇总表总是最新状态，或者定期运行一个批处理作业保持填充最新的数据信息，如果你采用后者，你的信息将会非常接近，但不是精确的，依赖于批处理作业多久运行一次，这需要权衡应用程序对精确信息的需要，和保持数据更新的系统开销，要在这二者之间找到一个平衡点。

4、优化子查询

遇到子查询时，MySQL查询优化引擎并不是总是最有效的，这就是为什么经常将子查询转换为连接查询的原因了，优化器已经能够正确处理连接查询了，当然要注意的一点是，确保连接表(第二个表)的连接列是有索引的，在第一个表上MySQL通常会相对于第二个表的查询子集进行一次全表扫描，这是嵌套循环算法的一部分。

5、优化UNION

在跨多个不同的数据库时使用UNION是一个有趣的优化方法，UNION从两个互不关联的表中返回数据，这就意味着不会出现重复的行，同时也必须对数据进行排序，我们知道排序是非常耗费资源的，特别是对大表的排序。

UNION ALL可以大大加快速度，如果你已经知道你的数据不会包括重复行，或者你不在乎是否会出现重复的行，在这两种情况下使用UNION ALL更适合。此外，还可以在应用程序逻辑中采用某些方法避免出现重复的行，这样UNION ALL和UNION返回的结果都是一样的，但UNION ALL不会进行排序。