OPTIMIZE TABLE无法批量执行，必须通过存储过程遍历information_schema.tables筛选InnoDB基表，拼接并预处理执行SQL；需过滤系统库、视图及非InnoDB表，注意权限、锁、超时及空间回收限制。
MySQL里OPTIMIZE TABLE不能批量跑，得靠存储过程拼SQL
直接写 OPTIMIZE TABLE 只能对单表生效，没有 OPTIMIZE DATABASE 这种语法。想重建整个库的索引（比如碎片整理、回收空间），必须手动遍历所有表，逐个生成并执行 OPTIMIZE TABLE 语句。存储过程是唯一可控、可复用的方式——但要注意它不自动提交，也不处理视图或临时表。
用information_schema.tables构造表名列表，避开系统库和非InnoDB表
查 information_schema.tables 是最稳妥的来源，但别漏掉过滤条件：跳过 mysql、information_schema、performance_schema、sys 这些系统库；同时排除 ENGINE != 'InnoDB' 的表（MyISAM 的 OPTIMIZE 行为不同，且可能锁表更久）。
常见错误现象：ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't have this option 就是因为没过滤引擎类型。
- 只查当前目标库：
TABLE_SCHEMA = DATABASE()或指定库名字符串 - 限定引擎：
ENGINE = 'InnoDB' - 排除视图：
TABLE_TYPE = 'BASE TABLE'
动态拼接+PREPARE/EXECUTE是唯一可行路径，不能用普通循环变量直接执行
MySQL 存储过程中无法把表名变量直接塞进 OPTIMIZE TABLE tbl_name，因为解析器在编译阶段就固化了语句结构。必须用字符串拼接 + PREPARE + EXECUTE 三步走，否则会报错 ERROR 1064 (42000) 或提示语法错误。
示例关键片段：
SET @sql = CONCAT('OPTIMIZE TABLE `', table_name, '`');
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
- 表名要加反引号
`，防止含特殊字符或关键字的表名出错 - 每次
EXECUTE后记得DEALLOCATE PREPARE，否则可能耗尽会话预处理语句资源 - 不要在循环里反复定义同名
stmt，否则PREPARE报错ERROR 1243 (HY000)
执行前务必确认权限、锁影响和超时设置
OPTIMIZE TABLE 对 InnoDB 表本质是重建聚簇索引+二级索引，会触发全表拷贝，期间原表可读不可写。如果库大、并发高、磁盘慢，很容易卡住或超时。
- 需要
ALTER和INDEX权限，仅SELECT不够 - 检查
innodb_lock_wait_timeout和wait_timeout，长事务可能让优化中途失败 - 生产环境建议加
IF NOT EXISTS判断表是否存在（虽然information_schema已筛过，但并发删表仍可能触发ERROR 1146） - 别在高峰期跑，尤其避免在从库上执行——主从延迟会飙升
真正麻烦的是：OPTIMIZE 不保证一定能释放空间，尤其是开启了 innodb_file_per_table=OFF 时，空间只还给 ibdata1，不会缩文件大小。这点很多人跑完发现磁盘没变小，就以为脚本没生效。
