MySQL性能提升那些事儿，聊聊实用又不复杂的优化方法

MySQL性能提升那些事儿，聊聊实用又不复杂的优化方法

直接上干货，很多人觉得数据库优化很深奥，其实从一些简单的地方入手，效果就很明显，咱们就聊点实在的,不用动不动就谈底层原理和复杂架构。

第一件事，先搞清楚“慢”在哪里。 你不能瞎优化，得找到瓶颈，最直接的工具就是MySQL自带的慢查询日志，把它打开（设置long_query_time参数，比如设为1秒），让它记录下所有执行得慢的SQL语句，这是优化的起点，你连哪些语句拖后腿都不知道，还优化什么？这是MySQL官方手册里推荐的首要诊断步骤，定期看看这个日志,重点关注那些执行次数多且慢的语句。

第二，给查询加“目录”——索引。 这大概是性价比最高的优化了，想象一下，一本没有目录的书，你要找某个内容得多难，索引就是数据的目录，怎么加？不是乱加,盯着慢查询日志来。

1. WHERE子句里经常用的字段，比如user_id、order_date,应该考虑加索引。
2. 连接（JOIN）用的字段，比如on a.user_id = b.user_id，两边的user_id最好都有索引。
3. 排序（ORDER BY）和分组（GROUP BY）的字段，索引也能大大加快速度。 但记住，索引不是越多越好，它就像书的目录，每多一个目录（索引）虽然查得快了，但写数据（增删改）时要更新更多目录，会变慢，索引要建在区分度高的字段上，比如给“性别”这种只有两三种值的字段建索引,效果几乎为零。

第三，写SQL语句要“懂事”。 很多性能问题是程序员的查询语句写得太随意。

• *别用`SELECT **，你需要什么字段就查什么，特别是别动不动就把TEXTBLOB`这种大字段带出来,网络传输和内存占用都浪费。
• 学会用EXPLAIN，在你要优化的SQL语句前加上EXPLAIN关键字执行一下，MySQL会告诉你它打算怎么执行这条查询（执行计划），虽然不复杂，但关键看几个点：type列是不是ALL（全表扫描，最差），如果是，说明很可能缺索引；rows列估算要查多少行，数字太大就要警惕，这是《高性能MySQL》这本书里反复强调的分析工具。
• 避免在WHERE子句里对字段做计算或函数操作，比如WHERE YEAR(create_time) = 2023，这会导致索引失效，应该写成WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。
• 小心关联子查询，有些用JOIN来写会比用子查询（特别是WHERE IN (...)）效率高很多,需要具体分析。

第四，有些配置可以调一调。 MySQL安装后有个默认配置文件，有些参数对性能有影响，根据一些资深DBA的社区经验，你可以关注两个地方（以InnoDB引擎为例）：

• innodb_buffer_pool_size：这是InnoDB最重要的缓存，用来存数据和索引，在保证系统不因内存耗尽而使用交换分区（swap）的前提下，可以适当调大，对于专用数据库服务器，设置成物理内存的60%-70%是常见的起点。
• 连接数：max_connections别设太小，不然应用会报“连接过多”的错误；但也别设太大，每个连接都要占用资源,根据应用实际情况调整。

第五，从设计上就考虑性能。 这算提前预防。

• 选择合适的数据类型，能用INT就别用VARCHAR，能用DATE就别用DATETIME，字段宽度够用就行,越小处理越快。
• 适度拆分大字段，把不常用的TEXT、BLOB字段单独拆到另一张表，让主表更紧凑,扫描更快。
• 想想数据会不会无限增长，对于日志、交易记录这类只增不删的数据，提前规划好归档或分表策略，别让一张表里有几千万行数据,那时再怎么优化索引都吃力。

别忘了最简单也最有效的一招——升级硬件。 很多时候，给数据库服务器加内存、换SSD固态硬盘，带来的性能提升是立竿见影的，而且比花大量时间优化代码要简单直接，这算是“硬优化”,在预算允许的情况下非常值得考虑。

MySQL优化不用一开始就想得太复杂，从开慢查询日志抓问题语句、有针对性地加索引、规规矩矩写SQL这三点做起，大部分常见的性能问题都能得到缓解，等这些基础工作都做到位了，如果还有瓶颈，再去深入研究更高级的架构方案，比如读写分离、分库分表，优化是一个持续的过程,不是一劳永逸的。