mysql索引 数据库优化
1.mysql索引结构b+树
a.首先要说二叉树，二叉查找树，数的结构不用多说，二叉查找树，大概就是几个原则，左边比右边的小，然后保持一个分布均匀，也就是树的高度尽量最小。
b.b-树，b-树和二叉查找树结构类似，但是每个节（页）点会有多个数据，
c.b+树和b-树最大的区别就是，只有叶子节点存数据。为啥，为了非叶子节点能够存储更多的索引，以便控制树的高度，树的高度决定了io次数，io是非常消耗性能的。
下图b-树
下图b+树
一般在数据库系统或文件系统中使用的B+Tree结构都在经典B+Tree的基础上进行了优化，增加了顺序访问指针。范围查找的时候等非常有用。
2.1000万数据的存储结构
在 MySQL 中我们的 InnoDB 页的大小默认是 16k，为16384
上图只是一个类似图，实际上根节点往往不止这点数据。
一上图2的高度来计算，假设前提是每页装满来算
结论1：根节点能存1170个指针（大概）
一页为16k（16384），我们假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节，我们一个页中能存放多少这样的单元，其实就代表有多少指针，即 16384/14=1170
结论2：一个叶子节点放16行数据
一页为16k，一行用1k来算的行就是16行。
结论3：高度为2的树数据为16*1170
根有1170个指针，一个指针指向一个页，一页有16条数据。
结论4：如果高度为3
1170*1170*13 大概2000w，第一层1170个指针，第二次每个也1170个指针，第三层叶子节点，每页为16行。
mysql不建议id用uuid或者雪花算法id，官方建议用自增id，其他id不是自增的，索引要保持有序性，需要磁盘数据重新挪动，产生io消耗。
mysql 锁
1.锁分类，表锁，行锁，页锁；共享锁，排他锁；乐观锁，悲观锁
2.innodb在增删改的时候回加上行锁，mysiam不会死锁，表级锁，查询的时候如果有索引会加上锁，如果每页条件，表级锁。
3.死锁。因为innodb的锁是分步获取的，比如事务a中，先获取id=1的数据，然后在获取id=2的数据；b事务中，先获取id=2，然后在获取id=1的数据。a，b事务会分别等待对方释放锁。
4. MVCC.MySQL InnoDB存储引擎，实现的是基于多版本并发控制协议—MVCC(Multi-Version Concurrency Control) MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突
https://blog.csdn.net/qq_38238296/article/details/88362999
1. 优化sql语句；
原则： 1.1 尽量根据主键查询；
1.2 尽量使用单表查询，不要使用关联查询；
1.3 查询时可以使用in，但是绝对不要使用not in；
2. 创建索引；CREATE INDEX 索引名字 ON 表名称 （列名称）；[列名称：规定你需要索引的列]。
3. 添加缓存；
例如：mybatis的一、二级缓存；该操作效率低；
redis缓存 / memercache缓存（String）；有效的缓解数据库的压力；
4. 使用数据库的读写分离；
5. 定期将历时数据进行转储；
6. 进行分库分表操作（最后的操作）；数据库服务器数量和运维都需要花费很多时间和精力
7. 数据库引擎选择
8. sql 语句分析 explain，其实就是看下各查询有没有用到索引，是不是失效了。
https://blog.csdn.net/fsdfkjai/article/details/121770629
1.联合索引 KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE，where条件写法，要先name，再age，再position
2.覆盖索引查询，不要select * 要select name，age 不用回表
3.索引列不做任何操作，WHERE left(name,3) = 'LiLei';
4.少用or或in，用它查询时，mysql不一定使用索引
5.mysql在使用不等于(!=或者<>)，not in ，not exists 的时候无法使用索引会导致全表扫描
< 小于、 > 大于、 <=、>= 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引
is null,is not null 一般情况下也无法使用索引
