TRUNCATE报错ERROR 1010说明误用了DROP DATABASE命令，该错误与TRUNCATE无关；真正因会话占用导致TRUNCATE阻塞时，SHOW PROCESSLIST显示“Waiting for table metadata lock”，需通过performance_schema查锁源并KILL对应会话。
TRUNCATE报错“ERROR 1010 (HY000): Error dropping database”说明不是会话占用，而是权限或连接残留问题
这个错误根本不是“会话占着表”，而是你误用了 DROP DATABASE 命令去删库——TRUNCATE TABLE 不会触发该错误。真正卡在“会话占用”场景下，常见的是执行 TRUNCATE TABLE 时被阻塞，SHOW PROCESSLIST 显示状态为 Waiting for table metadata lock，根源是其他会话正持有该表的元数据锁（MDL），比如正在执行长事务、ALTER TABLE、或未提交的 SELECT FOR UPDATE。
如何定位并踢掉占用表的活跃会话
先查谁锁着表：
SELECT t.object_name, t.lock_type, t.lock_duration, p.ID, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME, p.STATE, p.INFO FROM performance_schema.metadata_locks t JOIN performance_schema.threads th ON t.owner_thread_id = th.thread_id JOIN information_schema.PROCESSLIST p ON p.ID = th.processlist_id WHERE t.object_schema = 'your_db' AND t.object_name = 'your_table';
确认后，用 KILL 干掉对应会话 ID：
- 若
COMMAND是Sleep且TIME很大，大概率是应用没关连接，直接KILL ID; - 若
COMMAND是Query且STATE是Updating或Locked，说明它卡在 DML/DDL 中，也需KILL - 别信“等它自己结束”——MDL 锁不会因超时自动释放，必须人工干预
TRUNCATE前绕过MDL锁的临时方案：SET SESSION lock_wait_timeout = 1
这不是“强制清空”，而是让 TRUNCATE 快速失败，帮你暴露问题。设一个极短等待时间：
SET SESSION lock_wait_timeout = 1; TRUNCATE TABLE your_table;
如果立刻报错 ERROR 1205 (40001): Deadlock found when trying to get lock 或超时，说明确实有竞争；此时再回头查锁源，比盲等更高效。注意：lock_wait_timeout 只影响当前会话，不影响其他连接。
真正“强制”的代价：重启连接池或 MySQL 实例？不，别这么做
线上环境严禁靠重启解决 MDL 锁。更稳妥的做法是：
- 提前在业务低峰期操作，避免和应用写入冲突
- 确保所有应用使用短连接，或设置
wait_timeout缩短空闲连接存活时间 - 对关键表做 TRUNCATE 前，先执行
SELECT 1 FROM your_table LIMIT 1 FOR UPDATE;测试是否能快速加锁——能加锁，说明没被长期占用
MDL 锁的本质是串行化 DDL 安全性保障，绕过它等于放弃一致性。所谓“强制”，其实是精准识别并清理干扰源，而不是硬上。
