MySQLCPU100%：

• 大量的事务、函数、排序、类型转化
• io等待：导致tps下降、查询时间增加、慢查询增加、并发
• 增加索引减少io，增加redis和ssd提升io能力，减少函数、排序、类型转化、表结构多使用简单类型、合理拆分表
• 升级CPU

Waiting for table metadata lock

SQL语句优化：

• 避免在索引列上使用计算
• 避免在索引列上使用IS NULL和IS NOT NULL
• 用EXISTS替代IN、用NOT EXISTS替代NOT IN
• 应尽量避免在 where 子句中对字段进行表达式操作、null 值判断，否则将导致引擎放弃使用索引而进行全表扫描
• 尽量减少使用子查询和链接，如果能够拆分为小的SQL，用业务保证逻辑
• 使用子查询、连接、保存最大id优化大数据量分页
• 字段类型要正确对应

索引优化：

• 在where、on、order by、group by等条件列字段增加索引
• 增加适当数量的索引
• 模糊查询使用前缀后%
• 在区分度高、not null列增加索引
• 尽量使用复合索引，查询条件尽量是复合索引中的字段
• 不用或重写或查分SQL中的!=、<>等
• 用union代替or，或者or相关所有列都要有索引
• 条件列字段不使用函数、运算

大表优化

• 限定数据量的范围，800万以下
• 读/写分离，主库负责写，从库负责读

分库分表

生成全局ID

• UUID：不适合作为主键，太长且无序不可读，查询效率低
• 公用数据库自增ID: 需要独立部署数据库实例，成本高，有性能瓶颈
• Redis生成ID: 性能好，灵活，不依赖数据库
• Leaf分布式ID：全局唯一性、趋势递增、单调递增、信息安全，需依赖关系数据库、Zookeeper等中间件。

数据库优化

• 合适的引擎

数据量太大：

• mysql集群提供更多并发读写

参数调整：

• innodb_buffer_pool_size
• sort_buffer
• query_cache
• 链接数调整

硬件优化

• 高速磁盘、网络、内存、CPU

其他

• 增加Redis缓存，使用程序写入缓存或使用cannal订阅后写入缓存
• 事务中移出不必要的select