前言

最近在开发自己的小程序的时候，由于业务功能对系统性能的要求很高，系统性能损耗又主要在mysql上，而业务功能的数据表很多，单表数据量也很大，又涉及到很多场景的数据查询，所以我针对mysql调用做了优化，成功地把原本一次复杂请求的时间从3到5秒加速到0.5秒以内，顺便总结了一些mysql性能优化的方法

一 mysql配置调整

1.1 内存相关

1.1.1 innodb_buffer_pool_size

mysql数据页索引页缓冲区的大小： mysql中命中率高的数据页会长期驻留，读取数据时如果在buffer pool中，就无需访问磁盘，InnoDB的数据页和索引页都会缓存在这里，

对于专用数据库服务器，可以设为物理内存的60%~80%，但是要注意，如果设置得太高，会导致操作系统内存不足而swap，系统整体性能下降，而且内存竞争影响其他服务，可以通过以下语句监控buffer pool得命中率

SHOW ENGINE INNODB STATUS

如果status中的buffer pool hit rate命中率小于99%就说明太小了

1.1.2 innodb_log_buffer_size

redo log缓冲区的大小，事务执行过程中，修改操作写入内存中的log buffer，提交时flush到redo log 文件，redo log缓冲区用于存放事务提交前的redo日志，在事务提交时刷写到磁盘。

一般设置为 8MB~64MB（默认 16MB），如果事务频繁、单个事务很大，可以设置更大一点，减少磁盘写入次数，如果innodb_log_buffer_size设置得太小，会导致大事务频繁触发flush，性能下降，可以监控Innodb_log_waits，值大于 0 表示内存不够，

SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';

1.2 连接和并发

1.2.1 max_connections

服务器连接得最大并发连接数，超过该值的新连接会被拒绝。每个连接占用一定资源（内存+线程）

此参数是系统连接保护阈值。Web应用一般设置在 200~1000，高并发系统可适当调高，搭配连接池使用，设置太小时，高峰期连接被拒，出现 “Too many connections” 错误，太大时每个连接占用资源，连接过多会耗尽内存，崩溃风险增加，可以查看 Max_used_connections 是否接近 max_connections的值

SHOW GLOBAL STATUS LIKE 'Max_used_connections';

1.2.2 thread_cache_size

MySQL会重用已结束的线程，减少频繁创建线程的开销。线程结束后保留在线程缓存池中，下一个连接复用已有线程。

数据库服务一般设置为16~100，根据连接频繁程度和CPU核心数决定，设置太小时会导致Threads_created 值很高，频繁创建线程，影响性能，设置太大时占用内存资源而且提升不明显

SHOW GLOBAL STATUS LIKE 'threads_created';

1.2.3 table_open_cache

打开的表文件的缓存数量，避免频繁打开/关闭表文件，MySQL 每次访问表都会打开表文件，保存在 cache 中，复用效率更高。注意它缓存的是表文件的句柄和元数据结构，而不是表的数据变身

一般小型系统设置为512~2048，大表多或高并发可设为 8192，太小时会导致Opened_tables 值高，频繁打开表影响性能，太多则会占用过多内存，可以通过下面语句获取系统一共打开过多少次表文件

SHOW GLOBAL STATUS LIKE 'opened_tables';

你需要间隔一段时间（例如 1 分钟、5 分钟）对比两次结果，观察 opened_tables 的增长量。如果 5分钟内增长了几百甚至上千个，那就是异常的。正常情况下opened_tables 每分钟增长小于10 ，如果每分钟增长50到100之间，说明 table_open_cache 太小或有短连接频繁打开关闭表

也可以使用下面语句拿到获取表时命中缓存和没命中缓存的case数量，自行计算

SHOW GLOBAL STATUS LIKE 'Table_open_cache_hits';
SHOW GLOBAL STATUS LIKE 'Table_open_cache_misses';
 

命中率 = Table_open_cache_hits / (Table_open_cache_hits + Table_open_cache_misses)，通常命中率会大于95%，如果命中率小于90%，就应该考虑增加 table_open_cache

1.3 日志和事务

1.3.1 innodb_flush_log_at_trx_commit

这个配置控制事务redo日志何时写入磁盘

• 1：每次提交事务都同步写磁盘（最安全）

• 2：写OS缓存，根据系统自己的策略定时刷盘（折中）

• 0：仅写内存，崩溃时候redo日志全部丢失

高可靠性场景：设为1，对性能要求高并且允许少量数据丢失时设为2，数据丢失几乎不造成损失时可以考虑设置为0

1.3.2 sync_binlog

控制bin log刷盘频率，影响主从一致性。

• 1：每次事务都刷盘，最安全

• 0：交给操作系统定期刷盘，性能较高，但可能丢 binlog

• N：每 N 次事务刷一次

高可靠性场景下设为1，性能优先：设为 100 或更高

 

1.4 临时文件与排序

1.4.1 tmp_table_size和max_heap_table_size              

这两个配置控制临时表的最大内存使用，超出后写磁盘，前者控制MySQL 创建内部临时表（用于 GROUP BY、ORDER BY、DISTINCT 等操作）时，可使用的最大内存空间，后者控制用户或系统创建的MEMORY引擎表的最大大小，当 MySQL创建一个内存临时表时，会以 tmp_table_size 和 max_heap_table_size 中的较小值为准，作为临时表在内存中的最大可用空间

默认16MB太小，建议提升到 64MB~256MB,太小会导致临时表频繁写磁盘，性能下降

SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';

1.4.2 sort_buffer_size

每个线程排序操作使用的缓冲区大小。ORDER BY、GROUP BY 会使用此 buffer，如果不足会写磁盘

这个是单线程的变量，建议设置为2MB~8MB，太小时排序频繁落盘，影响性能，不过高并发场景不要设太大，因为每个连接消耗内存大，有服务器内存撑爆风险

SHOW GLOBAL STATUS LIKE 'Sort_merge_passes';

二 索引设计和sql优化

2.1 索引设计

2.1.1 合理的索引

覆盖索引：如果查询使用的索引语句包含了所有查询需要的字段，mysql就不需要回表查询表数据，大大提升性能

前缀索引：当字段是长字符串（如 VARCHAR 或 TEXT），为了节省索引空间和提升性能，可以只索引字段的前几位（前缀）。这样可以减少索引大小，但仍保持较好的查询效率。比如               

CREATE INDEX idx_email_prefix ON users(email(10));

表示只索引 email 字段的前 10 个字符。

组合索引：当查询条件涉及多个列时，可以将多个列联合建立一个索引。MySQL会将多个字段组合在一起作为一个整体进行索引，大大提升多字段查询性能。比如下面索引

CREATE INDEX idx_user_status ON users(user_id, status);

对于同时又user_id和status的查询就能够快速定位到。

2.1.1 避免不合理的索引设计

索引过多：索引不仅会占用磁盘空间，还是增加写操作的开销，建议不超过每表 5-6 个。不超过总字段的三分之一

避免长文本索引：普通索引会存储值的所有内容，对于很长的字段会占用很大的空间，对于前面部分的区分度就比较高的长字符可以使用前缀索引

2.2 SQL 语句优化

• 避免 SELECT *，只查需要的列

• 保证查询能使用到索引，对于组合索引和字符模糊匹配要注意最左匹配原则，尽可能利用覆盖索引

• 使用 EXPLAIN 分析执行计划，关注 type、rows、Extra 字段

• 大表避免 OFFSET 深分页，推荐“游标式分页”（如 WHERE id > ?）

• 避免 IN 过多项（>1000），或考虑改用临时表

• 联表限制：尽量不超过 3 张表JOIN，JOIN 字段必须加索引

• 尽量避免使用not in，or和union（尽可能用union all代替union）

• 避免索引列参与函数计算：WHERE DATE(create_time) = '2023-01-01' 会导致索引失效

三 应用系统

3.1 减少不必要的请求

• 缓存策略

  • 使用 Redis/Memcached 缓存热点数据。

  • 对于不变数据（如省市、用户等级），做本地缓存或CDN缓存。

• 连接池

  • 应用侧应使用数据库连接池，如 Druid、HikariCP，控制最大并发连接。

• 接口聚合

  • 尽量减少多次小查询，改为批量查询或数据合并。

3.2 数据库访问控制

• 限流与降级策略：高峰期临时关闭非核心查询。

• 使用读写分离：读请求走从库，写请求走主库。

• 使用中间层封装数据库访问（如 DAO 层），方面中间层做统一的优化管理，避免业务层直接操作 SQL。

3.3 持续监控与预警

• 使用工具如：

  • 慢查询日志 + pt-query-digest 分析慢 SQL。

  • Prometheus + Grafana 或 Percona Toolkit 做实时性能监控。

  • MySQL Enterprise Monitor 商业监控套件。

3.4 表设计

主键：优选整数型、自增主键（如 BIGINT AUTO_INCREMENT），避免使用 UUID 作为主键，因为UUID随机性太大，插入时会频繁触发页分裂

字段类型：明确字段类型，选择最合适的数据类型，字段长度固定的场景下使用定长字段而不是变长字段，使用最小足够类型，避免使用 TEXT/BLOB 除非确实要存大文本；这类字段性能差且不易索引

NULL值：非必要字段不要设置为 NULL，使用默认值（如 0、''）可减少 NULL 判断。

冗余字段：对于查询多写入少的情况可以适当添加一些冗余字段避免join操作影响性能