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 一般情况下也无法使用索引