Appearance
客户端和mysql的交互过程？
1.账号密码，权限验证，异常就拒绝；
2.查询缓存，中了就返回；
3.对sql进行语法解析；
4.优化器对解析树进行优化，生成最优的物理执行计划；
5.执行计划调用存储引擎的相关接口，进行数据查询和处理；
6.处理完成后将结果返回客户端；
三范式？
1.第一范式：原子性，字段具有原子性，不可再分割;
2.第二范式：唯一性，每一行都必须有一个唯一的标识（主键）;
3.第三范式：不重复性,不包含其他表的非主键字段;
设计规范
命名规范，不宜过长
每个表创建主键索引
合适的数据类型和长度，必须设有默认值
创建索引的原则？创建索引注意什么？
1.主键和外键应该有索引：主键和外键是用来唯一标识表中记录和实现关系连接的重要字段，因此为它们创建索引可以提高查询性能和维护数据完整性。
2.经常用于查询和排序的字段应有索引：如果某个字段经常用于查询条件或排序操作，那么为该字段创建索引可以加快查询速度和排序效率。
3.经常用于联表的字段应建立索引：如果表之间存在频繁的关联查询，那么涉及到连接的字段应该创建索引，以提高联表查询的性能。
4.索引应建立在小字段上：由于索引会占用额外的存储空间，因此应该将索引建立在小字段上，避免在大字段（如文本、大型BLOB）上创建索引。
5.谨慎建立复合索引：复合索引是指多个字段组合在一起创建的索引。在创建复合索引时，需要仔细分析查询语句中的条件，确保索引可以覆盖到常用的查询条件，避免创建过多无用的复合索引。
6.避免创建无用的索引：不应该为每个字段都创建索引，只有经常被查询的字段或需要通过索引进行连接的字段才需要创建索引。创建过多无用的索引会增加数据维护的成本并降低写操作的性能。
7.定期优化和维护索引：索引的性能和效果会随着数据的变化而变化，因此应定期进行索引优化和维护工作，包括重新构建索引、删除不再使用的索引等。
索引哪些？
1.普通索引:
2.主键索引:必须唯一，不可为空
3.唯一索引：可以空
4.联合索引：最左原则
5.全文索引：innodb5.7才开始支持
6.外键索引：myisam不支持;性能要求不高，一致性要求高时使用。作用①为了一张表记录的数据不要太过冗余。②保持数据的一致性、完整性。缺点：导致系统不好维护，插入时会进行查询，效率慢；
为什么要有主键？
1.数据库第二范式，数据的唯一性，每行都必须有唯一标识
2.B+树的节点都是拿一个唯一值来组织排序的，没有主键拿唯一索引，还没有就自动建一个列为维护，这样开销就大；用数字好排序，用字符串的话，大小不一样，还要维护索引的顺序；
为什么不用外键
数据库引擎支持：MySQL的不同存储引擎对外键的支持程度不同。例如，InnoDB引擎支持外键约束，而MyISAM引擎不支持。由于历史原因和性能考虑，一些项目可能选择了不支持外键约束的存储引擎，因此不使用外键成为一种常见做法。
性能考虑：外键约束的维护需要进行额外的检查和操作，可能对数据库的性能产生一定的影响。在某些高并发的场景下，为了提高数据库的性能和响应速度，开发人员可能会选择不使用外键。
灵活性和控制权：使用外键会限制了数据的操作，比如删除或更新主表记录时需要考虑外键关联的从表记录。有时候，开发人员可能更倾向于在应用层面实现数据的一致性和完整性控制，而不依赖于数据库的外键约束。
数据库迁移和兼容性：在进行数据库迁移或与其他数据库进行集成时，外键约束可能会引起一些兼容性和操作上的问题。为了简化迁移过程和减少潜在的兼容性问题，一些开发人员选择不使用外键。
尽管如此，外键约束在某些应用场景下仍然非常有用，特别是在保证数据一致性和完整性方面。在开发中，是否使用外键需要综合考虑具体的项目需求、性能要求和数据库引擎的特性，权衡利弊后做出决策。
主键索引和唯一索引区别
1.主键一定会创建一个唯一的值，但唯一索引不一定是主键；
2.主键不允许为空值，唯一索引可以为空；
3.一个表只能有一个主键，但可以有很多个唯一索引；
4.主键可作为其他表的外键，唯一索引不可；
5.主键是一种约束，唯一索引是索引
索引的工作原理？
1.索引使用的是B树，B+树；
2.作用：①创建唯一索引可以保证数据的唯一性；②提高查询效率；③加速表和表之间的连接；
3.缺点：占用物理空间;如果进行删除，修改时，索引也要进行动态的维护,更新表的速度会变慢;
索引是帮助mysql高速获取数据的排好序的数据结构
每个节点最大 innodb_page_size=16384(16k),
Btree,Btree-,Btree+
Btree:二叉树，树的高度比较高，造成查询慢
Btree-:平衡多路查找树,每个节点上都是二元数组[key,data],插入数会破坏性质；插入需要对数据进行转移，分裂，合并等，造成IO操作频繁
Btree+:非叶子节点不存data，只存key;
索引底层为什么使用B+树？
减少树的高度，减少查询次数就为定位到索引的位置；
InnoDB索引有哪些常见数据结构
innoDB索引常见的数据存储结构有Hash结构，B+树结构。
Hash结构
优点：
存储时只需要存储对应的哈希值，存储速度很快。
进行检索效率非常高，基本上一次检索就可以找到数据。
缺点：
Hash 索引不能进行范围查询。
Hash 索引不支持联合索引的最左侧原则。
Hash 索引不支持 ORDER BY 排序。
存在Hash冲突。
B+树结构
优点：
Btree索引可以加快数据的查询速度。
Btree索引更适合范围查找。
缺点：
命中的数据占用了表中大部分数据，那么mysql查询优化器会认为全表扫描方式更好。
不是按照最左原则，无法使用索引。
not in 和 <>也无法使用索引。
如果查询中有某个列的范围查询，则其右边所有的列都无法使用索引。
聚簇索引和非聚簇索引?
1.MYISAM是非聚簇索引，叶节点是索引节点，指向数据的位置；
2.INNODB是聚簇索引，叶节点就是数据;
3. INNODB 文件为.idb ，myisam 是.MYI，.MYD
4.聚簇索引优点：效率高;缺点：索引维护成本高;
聚集索引就是基于主键的索引，其它非主键的索引，统称为为聚集索引，也叫二级索引；
因为在一张innodb的表里，对应的物理文件就是按照B+树来组织的；
而聚集索引就是按照每张表的主键来构建B+树的，它的叶子节点存储了这个表里的每一行的数据；索引它不仅仅是一种索引类型，还是一种数据存储的方式；
同时还表示，每个表必须有一个主键；
如果没有主键，innodb会默认选择或新增一个隐藏列来构建B+树;
一般建议使用递增的id作为主键，这样数据也会按照顺序地存储在磁盘上；
索引最左前缀原则,为什么？
Index(a,b,c)
a=1 and b=1 命中
a=1 and c=1 不中
b=1 and c=1 不中
b=1 and a=1 命中 ,因为优化器
覆盖索引和回表？
覆盖索引：select的数据列只要从索引中就可获取，不必进行回表查询，（查询的数据列要被所建的索引覆盖）；
回表查询：非聚集索引查询到主键，再用主键进行查询，效率低
INNODB和MYISAM的区别是？
1.索引类型：INNODB是聚簇索引，MYISAM是非聚簇索引;
2.文件结构：INNODB有.FRM，.IDB；MYISAM有.FRM，.MYI，MYD,索引和数据是分开存储；
3.存储空间：INNODB：要更多的内存和存储空间，会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引；MYISAM:可被压缩，存储空间小,支持存储格式：动态表，静态表，压缩表;
4.可移植性、备份及恢复：INNODB:使用mysqldump在线热备份；数据量大时痛苦;MYISAM:数据是以文件的形式存储,转移方便，拷贝表文件,可针对某个表进行恢复备份; 5.事务支持：INNODB:支持事务；MYISAM:不支持; 6.表锁差异：INNODB:支持行锁,表锁;MYISAM：表锁； 7.INNODB支持MVCC; 8.索引：INNODB：5.7开始支持全文索引;MYISAM：不支持外键索引，允许没有任何主键或索引的存在； 9.表行数：MYISAM:会记录表的行数，全表查询select count 会比INNODB快; 10.默认引擎：5.5开始INNODB为默认引擎 11.MYISAM奔溃后无法安全恢复；；INNODB支持（redo log）
InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； InnoDB 是聚簇索引，MyISAM 是非聚簇索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而 MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快； InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一；
共享锁（读锁），排他锁（写锁）
读锁是共享的，不会阻塞其他读锁，可通过share in mode 实现，这时只能读不可写； 写锁是排他的，会阻塞其他读锁和写锁。从颗粒度上可分为表锁和行锁；修改表结构时会触发表锁， 表锁，行锁 表锁：表锁就是把整张表锁起来，加锁快，开销小，锁力度大，发生锁冲突的概率高，并发相对较低，（修改表结构时，悲观锁 where 没命中索引时） 行锁：行锁以行为单位锁起来，加锁慢，开销大，会出现死锁，锁冲突概率低，并发性相对较高，
悲观锁，乐观锁
都是表示为一致性的锁 悲观锁：Selct .. from ... for upate 强行加排他锁（必须命中索引,否则锁表）； 安全性高；在获取资源前对资源进行加锁，确保同一时刻只有有限的线程能够访问该资源，其他想要尝试获取资源的操作都会进入等待状态，直到该线程完成了对资源的操作并且释放了锁后，其他线程才能重新操作资源 但锁开销大，效率低;降低并行行，数据被锁必须等待；可能引起死锁; 乐观锁:读取数据同时读版本号，更新数据版本号实现（版本号+1）； 没有锁，效率高；
死锁？
概念
两个事务都持有对方的锁，并且都在等对方释放锁，并且双方都不会释放锁；
形成
1.系统资源不足 2.进程顺序运行不当 3.资源分配不当
处理
等待超时（innodb_lock_wait_timeout=50s） 开启死锁检测（innodb_deadlock_detect=on）
避免
1.查看死锁原因（SHOW ENGINE INNODB STATUS） 2.调试时，收集死锁日志（innodb_print_all_deadlocks） 3.不要把无关紧要的操作放进事务里，执行完事务就立即提交； 4.创建索引，可以使创建的锁更少； 5.使用合适的隔离级别； 6.尽量按照索引去查； 7.容易死锁的业务升级所级别，表锁减少死锁； 8.减少大事务; 9.不用locks tables；
间隙锁
可重复读隔离级别下才有，唯一索引无间隙索引
MVCC，幻读,MVCC和间隙锁的原理
MVCC：多版本控制，保存了数据在某个时间节点上的快照。 事务id只能看到自己本事务内的id，以及已经提交的事务id。其他事务的内容则看不到。 MVCC查找事务版本号<=当前版本号的，删除版本号为空或者大于当前版本号的； 为了确保读取的数据在开始就已存在，要么是自己插入或修改的； 幻读：MVCC和间隙锁可以解决； 间隙锁:范围查询或者加锁时，对于在范围且不存在的数据叫做间隙；它锁主这个区间，就无法插入新的数据了， 什么时候会用到事务？
事务的特点？
事务就是一组原子性sql的操作，要么全部成功，要么全失败 ACID 原子性：事务是最小的执行单位不可分割，要么全部成功，要么不生效；undo log（回滚日志保证事务的原子性） 一致性：执行数据前后，数据保持一致；其他三个特性保证之后，一致性才能保证 隔离性：多个事务不被其他事务所干扰；锁机制，MVCC保证隔离性， 持久性：事务提交后对数据的改变是持久的，redo log 保证事务的持久性
INNODB如何保证事务？（ACID如何保证？）
A（原子性）：由undo log日志保证，记录了需要回滚的日志信息，事务回滚时撤销已执行成功的sql；
C（一致性）：代码层面来保证；
I（隔离性）：MVCC
D（持久性）：由内存+redo log 来保证，修改数据时在内存和redo log 记录这次操作，事务提交时由redo log 刷盘，宕机时从redo log恢复；
Varchar 和char
Varchar:可变长度;
Char:定长；不够用空格补齐；最长存储255个字节；如果长度一样，用char会比较快
事务隔离级别？区别？
1.读未提交：所有事务都可以看到其他事务未提交的结果;脏读
2.读已提交：只能看到已提交的事务;不可重复度
3.可重复度：同一事务在并发读取数据时会获得相同的数据;幻读
4.串行化：最高的事务隔离级别，强制事务排序，使事务不冲突;每个读的数据上加上共享锁，可能导致大量的超时或者锁竞争;
事务隔离级别如何实现？
并发事务带来的问题？脏读，幻读，不可重复读
脏读：一个事务A正在修改数据未提交或回滚，事务B获取了获取了事务A修改后的内容并且使用了，之后事务提交，就引起脏读；（读未提交的隔离级别，主从延迟较大时） 幻读：多次读，多了一些数据；
不可重复度：一个事务执行两次，获取的数据不同，多次数据不同；（第一次之后有其他事务插入）
SELECT * 和SELECT 全部的区别
1.前者需要解析，后者不需要;
2.按照表的结构顺序，安装字段的顺序；
3.修改字段后，后者需要跟着修改；
4.后者可以建立索引优化;
5.后者的可读性更好;
安全
1.防止注入，对特殊字符进行转义，（addslashes(引号斜杆转)，urlencode(特殊符号转)，）
2.分配不同的用户,不同的库,不同的权限进行操作，并设置白名单ip，密码不用弱口令
3.Sql出错是不要将报错信息输出到客户端
4.定期备份，或者主从复制
5.使用预处理（PDO），参数绑定
update语句的执行流程
优化
MySQL性能优化
Mysql的性能优化，我认为可以分为4个部分 1.硬件和操作系统层面的优化 2.架构设计方面的优化 3.mysql配置层面的优化 4.sql执行优化 以下我对这4点进行详细描述， 1.从硬件层面来说，影响mysql性能主要因素是cpu，可用内存大小，磁盘读写速度，网络宽带；从操作系统来说，文件句柄数量，操作系统的网络配置，都会影响MySQL性能，这部分的优化一般由dba或运维工程师完成的；在硬件基础优化中，我们应该关注的点是，服务器本省所承载的体量，然后提出合理的指标要求，避免出现资源的一个浪费现象； 2.mysql是一个磁盘访问非常频繁的关系型数据库；在高性能和高并发的场景中，mysql必然会承受巨大的并发压力；在此我们优化的方式可分为一下几个部分，第一个搭建MySQL主从集群，单个mysql服务容易导致单点故障；一旦宕机mysql的应用全部无法响应，主从集群可保证服务的高可用；第二个，读写分离设计，读多写少的场景下，通过读写分离的方案，可避免读写冲突导致的性能问题；第三个可引入MySQL的分库分表机制，通过分库可减少单个服务器节点的io压力，通过分表可减少单表数据的数量，从而提高sql查询的效率； 第四个，对于热点数据，可以引入更为高效的分布式数据库redis，mongodb等，他们可以很好的缓解mysql访问的压力，同时还能提高数据的检索性能 3.可以通过修改my.cnf来完成，比如5.7的默认连接数是151个，这个值可在my.cnf修改，第二个binlog日志默认不开启的，我们也可以去修改开启；第三个是缓存池bufferpool默认大小配置等；这些配置一般和安装环境和用户的使用场景有关，具体情况还得使用者根据场景去修；修改这些配置需要关注两个方面，一个是配置得作用域，它可以分为会话级别和全局范围，第二个是是否支持热加载；针对这两点，全局参数的设定，对于已存在的会话是不生效的，会话级别的会随着会话的销毁而失效；第三个是全局类的统一的配置，建议配置在默认文件中，否则重启服务会导致配置失效， 4.sql优化有可以分为三个步骤；第一个慢sql的定位和排查，可通过慢日志去查看，慢查询日志工具分析，得到有问题的sql语句；第二个是执行计划，对慢sql可使用关键字explain，去查看当前的sql的执行计划，可以关注的点type，key，rows，filterd，从而定位该sql执行慢的根本原因，再去有优化；第三个使用show profile工具可以分析但前会话中sql消耗资源的情况，可用于sql调优测量，默认show profile是关闭的，开启后会保存最近15次的运行结果，比如会看到io开销，cpu开销，内存开销等； 以上就是我对该问题的理解 explain的type字段有哪些 All Index Range Index_merge Const system SQL语句优化 1.避免在where 后使用 !=,<>,not in,not exists,'%xx'查询,会放弃索引找全表; 2.避免隐式转换，索引进行计算；用or 必须全部字段都得设置索引；联合索引的最左匹配原则； 3.避免null值判断，确保没null值，给列设置默认值； 4.Exists 代替in 5.Where代替having，因为having查出来后再进行过滤的 6.Distinct 根据情况使用 group by ... order by... 7.使用连接代替子查询 8.LIMIT偏移量过大的优化，或者禁止偏移量太大， 禁止 limit 100860 10，是否能替换成上一页下一页那种select * from t_record where id > last_id limit 10；不然就 select * from table where id in (select id from table limit 100860 10) 9.减少使用select * ，借助覆盖索引，减少回表查询次数； 10.多表关联查询时，小表在前，大表在后； 11.根据业务，小范围事务；不用大范围事务； 12.查看慢查询日志，explain分析sql
索引优化
1.常搜的列上加索引; 2.用于连接的列上加索引； 3.常用范围查询的列加索引； 4.排序的列加索引； 5.常WHERE的加 6.很少用的不加索引； 7.Text，等不加，要么数据量很大，要么很小； 8.修改性能大于查询性能时不加；
表结构优化
合理的使用三范式；合理的加冗余字段； 分库分表；根据业务；
INNODB参数优化
读取参数 // global buffer 以及 local buffer； // Global buffer： Innodb_buffer_pool_size innodb_log_buffer_size innodb_additional_mem_pool_size // local buffer(下面的都是 server 层的 session 变量，不是 innodb 的)： Read_buffer_size Join_buffer_size Sort_buffer_size Key_buffer_size Binlog_cache_size
写入参数 innodb_flush_log_at_trx_commit innodb_buffer_pool_size insert_buffer_size innodb_double_write innodb_write_io_thread innodb_flush_method
与IO相关的参数 innodb_write_io_threads = 8 innodb_read_io_threads = 8 innodb_thread_concurrency = 0 Sync_binlog Innodb_flush_log_at_trx_commit Innodb_lru_scan_depth Innodb_io_capacity Innodb_io_capacity_max innodb_log_buffer_size innodb_max_dirty_pages_pct
服务器优化
加钱
分库分表
参考文章不停机迁移+无感降级，日均百万订单系统的分库分表咋做更靠谱？
MySQL数据量大几千万为什么要分表？
为了保证数据的完整性，在 DML 时需要给表或者行加锁，数据量越大，被锁的范围就越大，导致写入等待，占用系统资源，导致查询性能降低
什么时候分表，什么时候分库？
数据迁移？
1.双写迁移，写入操作时，写入新表和就表 2.写好的脚本，将旧数据写入新表 3.校验数据，直到完全一致 4.主从复制迁移，然后可删除冗余数据 好处坏处？ 好处：业务解耦，可以微服务治理；冷热数据分离； 坏处：无法join（跨库）；增加开发难度；分布式事务问题； 怎么分? 垂直分表：字段较多时，将不常用，数据较大的部分拆分； 水平分表：根据业务来分，比如按时间，hash(user_id)（id作为分片key）落到对应的表上，
分布式事务问题如何解决？
分布式事务:事务的参与者，管理者，支持事务的服务器，资源服务器分布在不同的节点上；一个大操作上有许多小的操作，每个操作都可能处在不同的服务器，应用上，分布式事务就是要保证这些操作，要么全部成功，或全失败； Xa，2pc，tcc 事务 过程 优点 缺点 其他说明 使用场景 XA(2PC) 简单,尽量保证强一致性 性能差;无perpase日志记录; 网络问题可能导致commit部分收到部分没收到，导致出现一致性问题 事务管理器：作为全局的调度这，负责各个本地资源管理器的提交和回滚; 本地资源管理器:本地数据库实现的XA接口 消息事务+最终一致性 1.开始发消息给mq； 2.然后执行sql,将结果发给mq； 3.发了确认，然后下个事务收到确认，开始执行 4.Mq会轮询，查询是否成功 5.失败就消息报警，手动回滚或补偿 非强一致性; 如果事务一直不成功，一致性就被破坏 金融，钱相关的，短事务 Tcc(柔性事务) 1.try:先检测资源，并锁定； 2.Confirm：各个节点中执行实际的操作; 3.Cancel:任何一个服务出错就进行补偿，进行事务回滚 强一致性 手写回滚逻辑，比较难，难维护 Saga(补偿事务) 1.一阶段提交无锁，本地性能高； 2.参与者可异步执行，高吞吐； 3.补偿事务容易实现（更新的发操作） 不保证事务的隔离性。只是最终一致性。 业务流程长，多的
如何保证ID唯一？
1.设置步长，n张表步长就为n；
2.分布式ID，比如雪花算法等；
3.根据业务用一个唯一值作为主键使用，比如订单号；
非sharding_key（分片key）查询呢？
1.根据业务建个表，里面保存的是 分片key 和 这个key的关系，先查这个表获取分片key，再查； 2.建立冗余数据表，再建一个这个key来分的表 3.每个节点都查询，然后合并数据
跨库JOIN如何解决？
1.全局表（数据字典），为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。 2.字段冗余（反范式），减少联表 3.数据同步，定时将A库的a表同步到B库的b表，需业务性能和时效性取得平衡 4.代码循环，先获取主表的，然后一个个循环获取其他表的信息；慢；
跨表查询怎么处理？
1.根据业务 2.建立个 字典表；比如 use_id,order_id,_table,找到就应的表 就 查 用union连接
跨库事务（分布式事务）的问题
主从复制
好处
复制的功能不仅有利于构建高性能应用，同时也是高可用、可扩展性、灾难恢复、备份以及数据仓库等工作的基础
流程
①主服务器提交完事务，记录了修改的语句写入binlog中； ②从服务器启动io线程，start slave，拉取到主服务器的binlog日志内容，写入到relay log中； ③从服务器执行sql线程，（串行）执行relay log中的语句；再写入自己的binlog中
读写分离
1.主从服务器各负责读和写，减少了锁的争用 2.可用性，数据备份，
说明
由于mysql复制的方式默认是异步的，主库发送日志后不关心是否处理，主库挂了，从库处理丢失数据，从库升级为主库了。 全同步复制：binlog给所有从库处理完才能功，性能差 半同步复制：一个从库处理成功就算成了
如何保证数据一致性
如果主从这种结构写完主节点，这个主数据库刚好就挂了，它还没有同步到节点，会不会存在数据丢失？
数据不一致如何排除，主从延迟
1.主从库尽量放一个机房（用内网ip）； 2.主从硬件配置差别是否大； 3.查看那个从库的查询负载是否过大，加从库； 4.主库并发是否过大？大事务？ 5.资源不足？ 6.是否有执行比较长的事务或语句，导致从库执行也要较长的时间 7.如果是一写入就要查询的，建议查主库
Redo，undo日志
1.Redo（重做日志）：保证事务的持久性 2.Undo（回滚日志）：保证事务的原子性
事务如何通过日志来实现？
Binlog的几种日志和作用和区别
Statement:记录sql语句和上下文的相关信息，函数无法复制 Row:记录单元每一行的改动，基本全记录下来，信息多，日志大 Mixed:折中操作，普通操作用statement记录，无法使用statement就用row
MYSQL CPU飙升如何处理？
Showprocess查看杀掉 1.top -Hp pid 查看线程 2.锁使用不当 3.突然出现大量请求
工具
重启多台db:pssh,salt 监控数据库：lepus,zabbix; 主从一致性校验:checksum、mysqldiff、pt-table-checksum
是否拆表？
拆表问题：连接的消耗+存储拆分空间； 不拆问题：可能查询性能低； 同一个字段，用 int 还是 char 查询效率高?
MYSQL批量插入很多条数据？如何操作？
索引查找在Linux的磁盘上是怎么操作的 MySQL的IO过高怎么优化 innodb为什么必须要有主键索引