做图书出版 外国网站,wordpress 收费下载,wordpress 有赞收款,wordpress 用户枚举一、索引
使用一定的数据结构#xff0c;来保存索引字段对应的数据#xff0c;以后根据索引字段来检索#xff0c;就可以提高检索效率。
一定的数据结构--需要一定的空间来保存
建立索引#xff1a;类似于建立书籍目录或者手机电话簿
使用索引#xff1a;查询条件…一、索引
使用一定的数据结构来保存索引字段对应的数据以后根据索引字段来检索就可以提高检索效率。
一定的数据结构--需要一定的空间来保存
建立索引类似于建立书籍目录或者手机电话簿
使用索引查询条件中的字段能够命中索引
创建索引更新/删除索引字段插入数据都会导致索引更新的耗时操作
数据库保存数据的基本单位page目的硬盘读取文件到内存的io操作时耗时操作读取数据最好能最少次读取到需要的结果集
MySQL中有多种索引类型
1从索引存储结构划分B Tree索引、Hash索引、FULLTEXT全文索引、R Tree索引
2从应用层次划分普通索引、唯一索引、主键索引、复合索引
3从索引键值类型划分主键索引、辅助索引二级索引
4从数据存储和索引键值逻辑关系划分聚集索引聚簇索引、非聚集索引非聚簇索引
5从索引列数量划分单列索引、复合索引
创建的某个索引可以是以上多种类型
B树所有节点都保存有索引列及数据B树叶子节点保存有索引列和数据非叶子节点只有索引字段B树搜索路径是从根节点搜索到叶子节点比链表查询效率高B树非叶子节点可以存储更多的数据此时树就更矮搜索路径更短io次数更少
1.主键索引---唯一索引
默认B树聚簇索引B树的叶子节点上存放主键字段索引字段及数据
一张表只能有一个聚簇索引
主键索引---叶子节点 id_number整行数据
优点速度快缺点主键需要是整型且字段不要太长更新代价大效率低
2.非聚簇索引
非主键索引都是可以是有很多种类型的索引如B树、Hash索引等
如使用B树存储结构叶子节点存放索引字段值主键的值
age字段建立B树索引---叶子节点 age的值id_number的值
优点更新代价相比于聚簇索引小叶子节点是索引值和主键值没有真实数据缺点1也依赖有序数据2回表操作导致效率更低
搜索数据的方式
1先通过索引字段找到叶子节点上的主键值
2再通过主键值赵正条数据回表操作存在回表说明效率比主键索引慢
3.覆盖索引
如果一个索引包含或者说是覆盖所有需要查询的字段的值我们就称之为“覆盖索引”
语法select 覆盖索引字段 from 表 where 覆盖索引字段...
特殊的有些操作不会走索引is null、is not nullselect name from table where nameguang19;原因检索的时候是根据name索引字段来检索name是在叶子节点排序的查询字段又没有其他字段所以就不需要回表
4.复合索引
使用多列来创建索引涉及最左匹配原则索引创建的字段顺序从左到右匹配
ALTER TABLE table ADD INDEX index_name(num,name,age)
select...from 表 where num.. and name... and age...---覆盖索引效率高、select...from 表 where name... and num...---符合索引最左匹配原则select * from 表 where name... and age...---不符合索引最左匹配原则
查询的条件字段顺序无所谓关键是索引创建的字段顺序 基于B树的索引 1主键索引聚簇索引 2非聚簇索引 优化原则 1索引字段尽量不要有null值 查询的时候条件是--字段 is [not] null 会走全表扫描不会走索引 like的操作匹配a开头a%---可以走索引匹配包含a或以a结尾---不可以走索引 2频繁查询的字段建立索引需要考虑最左匹配原则顺序是左边 3频繁更新的字段慎用索引索引更新代价大 5.hash索引
hashmap存储数据的特性键值对、无序、键唯一不重复
底层数据结构数组链表红黑树
原理存取元素复杂的都是put流程往火车放东西
1算数组位置往上边放根据key的hashcode值基于内部hash函数计算出数组索引--找车厢
2如果该位置没有元素放这个位置上车厢是空的
如果这个位置有元素--- 往链表上放是否存在节点equals(key) ---存在替换车厢位置有人他走放我自己的不存在考虑头插尾插-》可能转红黑树
3如果放进去了东西可能需要扩容
缺点不支持顺序和范围查询
二、事务
1.事务的特性
1原子性事务是最小的执行单位不允许分割。即多条sql要么都执行要么都不执行
2一致性执行事务前后数据保持一致性。比如转账业务中无论事务是否成功转账者和收款人的总额应该不变
3隔离性并发访问数据库时一个用户的事务不被其他事务所干扰各并发事务之间数据库时独立的(不同隔离级别下可能不一定满足某种场景的隔离性
4持久性一个事务被提交之后它对数据库中数据的改变时持久的即使数据库发生故障也不应该对其有任何影响事务提交后数据会持久化到硬盘中 start transaction; -- 阿里巴巴账户减少2000 update accout set money money-2000 where name阿里巴巴; -- 四十大盗账户增加2000 update accout set money money2000 where name四十大盗; 开启事务后sql相关操作都是在内存中执行
rollback--回滚内存中执行的回滚不执行
commit--提交内存中修改的操作执行写入硬盘
事务中不同隔离级别一个事务修改的数据其他事务可不可见要根据隔离级别。
2.事务会出现的问题
1丢失更新
事务1修改数据的操作在事务2修改以后就覆盖掉了相当于丢失。
2脏读
第一个事务修改数据后还没有提交第二个事务就读取此时第一个事务回滚后第二个事务读取的就是脏数据。
3不可重复读
一个事务两次读取数据中间有另一个事务修改第一个事务两次读取的数据就不同不一致
4幻读
一个事务两次读取中间有另一个事务执行了插入操作造成第一个事务看到不同的结果。
解决以上问题就使用到了隔离级别
3.隔离级别
从低到高的级别级别越高越安全但是性能越差
1未提交读read uncommitted---一般都不会使用
事务中的修改即使没有提交对其他事务也是可见的。
2提交读read committed---用的比较广泛的
一个事务只能读取已经提交的事务所作的修改即一个事务所作的修改在提交之前对其他事务不可见。
3可重复读repeatable read---MySQL默认的隔离级别
保证在同一个事务中多次读取用一个数据的结果是一样的。
4可串行化serializable---公司几乎也不适用因为性能太差
强制事务串行执行这样多个事务互不干扰不会出现并发一致性问题。
串行执行---一个事务中多行sql全部执行完提交或者回滚另一个事务才能执行。
脏读不可重复读幻读未提交读×××提交读√××可重复读√√×可串行化√√√
