数据库压力大的核心是精准定位瓶颈：慢查询需通过slow_query_log和EXPLAIN分析type/key/rows，避免函数索引失效、大OFFSET及违背最左前缀；php层应缓存低频数据、显式读写分离、批量操作；事务须短小并移出非DB操作；连接池应合理配置持久连接与单例复用。
数据库压力大，不是光加索引或换服务器就能解决的；核心是识别瓶颈在哪——是慢查询拖垮了连接池？还是事务锁住了热点行？或是 PHP 层反复查同一张表却没缓存？
查慢查询：用 slow_query_log 和 EXPLAIN 定位真实瓶颈
很多“高并发”问题其实只是几条没走索引的 select 在反复执行。mysql 默认不开启慢日志，得手动配：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5;然后看 slow.log，挑出频次高、耗时长的 SQL，对它跑 EXPLAIN。重点盯 type（别是 ALL）、key（是否用了索引）、rows（扫描行数是否远超返回行数）。
- 如果
WHERE条件含函数（如date(created_at)），索引大概率失效，改用范围查询 -
ORDER BY和LIMIT配合时，避免OFFSET过大，考虑用游标分页（比如记录上一页最大id） - 联合索引要符合最左前缀，
(a,b,c)能加速WHERE a=1 AND b=2，但对WHERE b=2无效
减少 PHP 层数据库交互：读写分离 + 查询结果缓存
PHP 每次请求都连 MySQL、查配置、查用户权限、查菜单……这些低频变动数据，不该每次都走 DB。
立即学习“PHP免费学习笔记（深入）”；
- 用
redis缓存查询结果，比如$redis->get('user:123:profile')，过期时间设短一点（如 30 分钟），更新时主动del - 读写分离别只靠中间件自动路由；在 PHP 里显式指定：写用
$pdo_write，读用$pdo_read，避免事务中意外读从库导致脏数据 - 批量操作别用循环
INSERT，改用INSERT INTO ... VALUES (...), (...), (...)一次提交
事务控制不当是隐形杀手：缩短事务生命周期
一个 BEGIN 后跟了 3 秒的 http 请求处理，再 COMMIT，等于把行锁/表锁占了 3 秒——别人全卡住。
- 事务里只放真正需要原子性的 DB 操作，把日志记录、API 调用、文件写入等移出去
- 避免在事务中做
SELECT ... for UPDATE后又等用户输入，这类逻辑必须拆成两阶段：先锁、再处理、再更新 - 用
innodb_lock_wait_timeout设低一点（比如 5 秒），让死锁或长等待快速失败，PHP 层捕获Deadlock found when trying to get lock后重试
连接池不够用？别急着调 max_connections
MySQL 的 max_connections 不是越大越好。每个连接吃内存（默认约 2–3MB），设太高可能直接 OOM。更关键是 PHP 怎么用连接：
- CLI 脚本用完不
$pdo = NULL或不unset($pdo)，连接不会释放，容易堆满 - Web 场景下，用
PDO::ATTR_PERSISTENT => true开持久连接，但要注意：它不支持事务跨请求，且错误状态不会自动清理 - 比调参更有效的是复用连接对象：laravel 的
DB::connection()、thinkphp 的Db::name()->...底层都做了单例管理，别每次 new PDO
真正难的不是知道该加缓存或分库，而是判断哪条 SQL 值得缓存、哪个事务边界该切在哪、什么时候该放弃 MySQL 改用消息队列削峰——这些得看监控（如 SHOW PROCESSLIST、information_schema.INNODB_TRX）、看业务语义，而不是套模板。