MariaDB 10.11 在宝塔面板中默认配置易引发高并发锁死，核心原因是未适配新版本行为：innodb_lock_wait_timeout 过长（50秒）、lock_wait_timeout 极高（1年）、innodb_deadlock_detect 可能被关闭、max_connections 远低于 PHP-FPM 并发数，导致锁等待迅速蔓延。
直接说结论：MariaDB 10.11 在宝塔面板中默认配置无法支撑高并发写入，核心瓶颈不是 SQL 写得差，而是锁等待（Waiting for table metadata lock、Waiting for lock）在事务未及时提交或长查询堆积时迅速蔓延，导致后续所有 DML 操作卡死。
为什么 MariaDB 10.11 在宝塔里容易锁住？
宝塔安装的 MariaDB 10.11 默认沿用旧版 my.cnf 模板，关键参数未适配新版本行为：
-
innodb_lock_wait_timeout仍为 50 秒（太长），一个慢事务会拖垮整条链路 -
lock_wait_timeout（全局 DDL 锁超时）默认 31536000 秒（即一年），ALTER TABLE卡住时，其他连接全被阻塞 - 未启用
innodb_deadlock_detect = ON（MariaDB 10.11 默认是 ON，但宝塔某些镜像模板会覆盖为 OFF） -
max_connections默认 151，而宝塔常配 PHP-FPMpm.max_children = 800，连接池远超上限，大量连接在排队等连接，间接加剧锁等待感知
必须改的四个核心参数（宝塔内实操）
进入宝塔【软件商店】→ 找到已安装的 MariaDB → 【设置】→ 【配置修改】，定位到 [mysqld] 区块，添加或修改以下项：
-
innodb_lock_wait_timeout = 10（从 50 降到 10，让锁冲突更快失败，避免雪崩） -
lock_wait_timeout = 60（DDL 操作超时设为 60 秒，防止ALTER卡死整库） -
innodb_deadlock_detect = ON（确认此项存在且值为 ON；若无则手动添加） -
max_connections = 2048（必须 ≥ PHP-FPMpm.max_children，否则连接拒绝本身就会触发重试+锁堆积）
改完后务必点击【重启数据库】——只点【重载配置】不生效，因为部分参数是启动时读取的。
查锁和杀锁的命令别只靠 phpMyAdmin
phpMyAdmin 刷新慢、权限受限，真正排障要直连终端：
- 看谁在等锁：
SELECT * FROM information_schema.INNODB_TRX\G（重点关注TRX_STATE、TRX_STARTED、TRX_MYSQL_THREAD_ID） - 看锁等待关系：
SELECT * FROM information_schema.INNODB_LOCK_WAITS\G（能直接看到 blocking_trx_id 和 waiting_trx_id） - 强制杀掉肇事线程：
KILL <code>thread_id;（thread_id来自上一步的WAITING_TRX_ID对应的线程 ID） - 临时禁用自动提交排查问题：
SET autocommit = 0;后务必跟COMMIT或ROLLBACK，宝塔后台任务脚本常漏写
最容易被忽略的“伪优化”陷阱
很多人调大 innodb_buffer_pool_size 就以为万事大吉，但在 MariaDB 10.11 + 宝塔环境下，这反而可能放大锁问题：
- buffer pool 过大会挤占系统内存，触发 Linux OOM Killer 杀掉 mysqld 进程，日志里只留
Killed process，误判为锁问题 - 没配合调
innodb_log_file_size（建议设为 buffer_pool 的 25%），会导致频繁 checkpoint，写放大加重锁竞争 - 宝塔默认关闭
innodb_file_per_table = ON（实际是 ON，但某些升级残留配置会关掉），一旦关掉，DROP TABLE会锁整个共享表空间，影响所有库
真实高并发场景下，锁等待从来不是单点参数能解决的，它暴露的是事务边界不清、PHP 层未设超时、SQL 未加索引、以及宝塔默认配置与 MariaDB 新版本行为之间的错配。动手改之前，先用 SHOW ENGINE INNODB STATUS\G 抓一次实时锁快照，比盲目调参有用十倍。
