MySQL安装后必须调整的5个关键配置项：innodb_buffer_pool_size设为内存50%–75%，max_connections按连接池用量加20%余量，sort_buffer_size和read_buffer_size建议保持默认，innodb_log_file_size设为buffer pool的25%并需停库修改，tmp_table_size与max_heap_table_size必须相等。
MySQL安装后必须调整的5个关键配置项
刚装完MySQL直接跑量业务，90%会遇到慢查询、连接超时或OOM。不是MySQL不行，是默认配置专为测试机设计，必须改。
重点调这5个参数，顺序不能乱：
-
innodb_buffer_pool_size：设为物理内存的50%–75%，但别超80%。例如16GB内存，设12G；32GB以上建议分实例或用innodb_buffer_pool_instances=8拆分 -
max_connections：别盲目设成1000+。先看应用连接池实际用量（如Druid监控里的ActiveCount），再加20%余量。设太高反而触发OS文件句柄不足 -
sort_buffer_size和read_buffer_size：单个线程内存分配，全局设太大易引发内存抖动。建议保持默认（256K/128K），必要时在SQL里用SET SESSION sort_buffer_size = 2M临时调高 -
innodb_log_file_size：日志文件总大小（innodb_log_files_in_group × innodb_log_file_size）建议为buffer pool的25%。改这个要停库删旧日志，切勿在线改 -
tmp_table_size和max_heap_table_size：必须设相等，否则内存临时表自动转磁盘。大数据GROUP BY或ORDER BY前务必检查
大数据导入时避免锁表和崩溃的操作方式
用INSERT INTO ... SELECT或LOAD DATA INFILE批量写入千万级数据，不控制节奏等于找死。
- 关掉唯一键和外键检查：
SET unique_checks=0; SET foreign_key_checks=0;，导入完再开 - 用
--disable-keys参数配合mysqldump导出，导入时会延迟建索引 - 分批次插入：每批
1000–5000行，用COMMIT隔开。避免事务过大撑爆innodb_log_file_size - 禁用autocommit：
SET autocommit=0，自己控制提交时机。但别一个事务包全量数据 - 导入前执行
ALTER TABLE t ENGINE=InnoDB ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，压缩率能到40%，尤其适合文本字段多的表
慢查询定位不到真实瓶颈？先查这3个隐藏开关
开了slow_query_log却看不到慢SQL？大概率被下面三个配置拦住了。
ChatGPT网站生成器，AI对话快速生成网站
-
long_query_time默认是10秒，对OLTP毫无意义。设成0.5或1才抓得到真实问题SQL -
log_queries_not_using_indexes默认关闭。打开它，能立刻暴露缺失索引的高频查询（注意：只记录没走索引的SELECT，UPDATE/DELETE不记） -
min_examined_row_limit默认0，但线上可设成1000，过滤掉只查几行的“伪慢查询”，聚焦真问题
查完记得用pt-query-digest分析日志，别肉眼扫slow.log。
加了索引查询还是慢？InnoDB聚簇索引的硬约束
大数据量下，索引失效不是因为写法错，而是InnoDB本身限制。
- 主键必须是
B+树且有序，用UUID或随机字符串当主键，写入性能直接腰斩。换成BIGINT AUTO_INCREMENT或ULID - 联合索引最左匹配不是“模糊匹配”，是严格前缀。比如索引
(a,b,c)，WHERE b=1 AND c=2完全用不上 -
ORDER BY字段没包含在索引里？InnoDB必须回表排序，数据量一过百万，Using filesort就是性能断崖点 - 别迷信
CARDINALITY。用ANALYZE TABLE更新统计信息后，再看SHOW INDEX FROM t，否则执行计划可能误判
真正卡住的往往不是SQL怎么写，而是表结构设计时没想清楚模式。
