标签：ted atom 事务 平衡 body top 技术 除了 关键字
架构、索引、锁、语法、理论范式
1、加快查询数据速度（在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。索引的出现就是为了提高查询效率，就像书的目录。其实说白了，索引要解决的就是查询问题。）
1、主键、唯一键和普通键等
主流索引是B+Tree 。此外还有hash结构和bitmap等，其中mysql不支持bitmap索引。
1、生成索引、建立二叉查找树进行二分查找（平衡二叉树、线性二叉树、）
影响程序的数据速率和io还有关系，数据库中二叉树查找每一个深度就会产生一次IO。
2、生成索引、建立B-Tree结构进行查找
→ 根节点至少包括两个孩子。
→ 树中每个节点最多含有m个孩子（m>=2）
→ 除根节点和叶节点外，其他每个节点至少有ceil（m/2）个孩子
Ceil：取上限
→ 所有叶子节点都位于同一层，叶子节点的高度相同
3、生成索引、建立B+-Tree结构进行查找（MySQL主要是通过此方式实现索引）
4、生成索引、建立Hash结构进行查找
B+树是B树的变体，其定定义基本与B树相同，除了以下几点
→ 非叶子节点的子树指针与关键字个数相同
→ 非叶子节点的子树指针P[i]，指向关键字值[K[i],k[i+1]]的子树
→ 非叶子节点仅用来索引，数据都保存在叶子节点中
→ 所有叶子节点均有一个链指针指向下一个叶子节点（方便做统计）
结论（B+ Tree更适合用来做存储索引）
→ B+ 树的磁盘读写代价更低（关键字都是存在节点中，节点中并不存放数据，这样一次读到内存中的关键字就比较多，io读取次数也降低了）
→ B+ 树的查询效率更加稳定（内部节点并不是最终指向文件内容的节点，只是指向叶子节点中关键字的索引，所以每个查询都是从根节点开始）
→ B+ 树更有利于对数据库的扫描（B+树只要遍历叶子节点就可以对全部信息的扫描，范围查询之类的就比较方便）
缺点
→ 仅仅能满足“=”，“in”，不能使用范围查询
→ 无法被用来避免数据的排序操作
→ 不能利用部分索引键查询
→ 不能避免表扫描
→ 遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高
→ 密级索引文件中的每个搜索码值都对应一个索引值
→ 稀疏索引文件只为索引码的某些值建立索引项
InnoDB（mysql）
→ 若一个主键被定义，该主键则作为密集索引
→ 若没有主键被定义，该表的第一个唯一非空索引则作为密级索引
→ 若不满足以上条件，innodb内部会生成一个隐藏主键（密集索引）
→ 非主键索引存储相关键位和其他对应用的主键值，包含两次查找
MyIsAM中的数据和索引是分开存放在不同的文件中（.MYD，.MYI），innodb索引和数据是存放在一个文件中（.idb），都有一个.frm文件存放表结构。
1、根据慢日志定位慢查询sql
执行 show variables like ‘%query%’；
查看slow_query_log这个变量有没有开启，若没有则需要开启（set global sow_query_log = on），改变long_query_time的值，默认为10s，改为1秒（set global sow_query_time = 1 ）。
执行show status like ‘%slow_queries%’；
查看慢日志中的慢查询条数，然后在查询语句前加上explain 进行分析
2、使用explain等工具分析sql
然后在查询语句前加上explain 进行分析（结果中的两个字段比较重要type，extra）。
3、修改sql或者尽量让sql走索引
给表中某个字段增加索引（alter table xxx add index idx_strName(strName)）
1、最左前缀匹配原则,非常重要的原则，mysql会一直向右匹配直到遇到范围查询（>、<、between、like）就停止匹配，比 a = 3 and b = 4 ,c > 5 and d = 6 ;如果建立（a、b、c、d）顺序的索引，d是用不到索引的，如果建立（a、b、d、c）的索引则都可以用到，abd的顺序可以任意调整。
2、“=”和“in”可以乱序，比如a = 3 and b = 4 ,c = 5建立（a，b，c）索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式。
数据量小的表不需要建立索引，建立会增加额外的索引开销
数据变更需要维护索引，因此更多的索引意味着更多的维护成本
更多的索引意味着也需要更多的空间
MyISAM默认用的是表级锁，不支持行级锁
InnoDB默认用的是行级锁，也支持表级锁
lock tables xxx read|write；-- 给xxx表增加读锁
unlock tables；-- 释放锁
→ 频繁执行全表count语句
→ 对数据进行增删改的频率不高，查询非常频繁
→ 没有事物
→ 数据增删改查都相当频繁的
→ 可靠性要求比较高，要求支持事物
按所得粒度划分
表级锁、行级锁、页级锁
按锁级别划分
共享锁、排它锁
按加锁方式划分
自动锁、显示锁
按操作划分
DML锁（表中数据操作的）、DDL锁（表结构发生变化的）
按使用方式划分
乐观锁、悲观锁（排它锁的锁定即可实现）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
事物隔离级别以及各级别下的并发访问问题
→更新丢失 — mysql所有事物隔离级别在数据库层面上均可避免
→脏读 — read-committed 事物隔离级别以上可避免（脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。）（oracle的默认隔离级别）
→不可重复读 — repeatable-read事物隔离级别以上可避免（不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。）（mysql的默认隔离级别）
→幻读 — Seriaizable事物隔离级别可避免（幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。）
|
事物隔离级别 |
跟新丢失 |
脏读 |
不可重复读 |
幻读 |
|
未提交读 |
× |
√ |
√ |
√ |
|
已提交读 |
× |
× |
√ |
√ |
|
可重复读 |
× |
× |
× |
√ |
|
串行化 |
× |
× |
× |
× |
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
1、Group by
a、满足“select 字句中的列名必须为分组列或列函数”
b、列函数对于group by自居定义的每个组各返回一个结果
2、Having
a、通常与group by 子句一起使用
b、where过滤行，having过滤组
c、出现在同一sql的顺序：where 》 group by 》 having
3、Count、sum、max、min、avg
标签：ted atom 事务 平衡 body top 技术 除了 关键字
原文地址：https://www.cnblogs.com/long88-club/p/11415321.html
