用途：在 MySQL/InnoDB 上做安全、可测量的变更规划和审查，覆盖表结构、索引、查询、事务和运维。
工作流：先明确负载与约束（读写比例、延迟目标、数据量、MySQL 版本、托管平台）；只读取相关参考文件；提出最小可行改动并说明权衡；用 EXPLAIN、EXPLAIN ANALYZE、锁与连接指标等证据验证；生产变更需包含回滚与部署后验证。
主要能力：表结构方面，写密集 OLTP 表优先使用窄的单调主键（BIGINT UNSIGNED AUTO_INCREMENT），避免随机 UUID 作聚簇主键，统一 utf8mb4 / utf8mb4_0900_ai_ci，优先 NOT NULL，DATETIME 优于 TIMESTAMP，用查找表代替 ENUM，规范到 3NF，仅在实测热点路径反规范化。索引方面，组合索引顺序为等值在前、范围/排序在后（最左前缀），范围谓词会中断后续列使用，二级索引隐式含主键，长字符串可用前缀索引，可借 performance_schema 审计并删除 count_read = 0 的索引。分区适用于时间序列（>5000 万行）或大表（>1 亿行），需提前规划，唯一键/主键必须含分区列，并加 MAXVALUE 兜底。查询优化：检查 EXPLAIN 中 type: ALL、Using filesort、Using temporary 等危险信号；使用游标分页而非 OFFSET；避免在 WHERE 中对索引列用函数；批量插入 500–5000 行；无需去重时用 UNION ALL。事务与锁：默认 REPEATABLE READ（间隙锁），高竞争可用 READ COMMITTED；一致的访问顺序防死锁，错误 1213 需退避重试；I/O 操作放在事务外，少用 SELECT ... FOR UPDATE。运维：尽可能用在线 DDL（ALGORITHM=INPLACE）并在副本先测试；调优连接池避免 max_connections 耗尽；监控复制延迟，避免副本脏读。
限制与注意：优先依据实测证据而非笼统经验；给出建议时需注明 MySQL 版本差异；执行破坏性数据操作（DROP/DELETE/TRUNCATE）前必须获得明确的人工批准。资料还提到 PlanetScale 是托管 MySQL 的推荐平台，但若用户自托管或使用其他服务商应尊重其选择。具体命令与各参考文件名见原始资料，此处不展开。