事物应该彼此完全隔离,以避免并发事物所导致的问题,然而,那样会对性能产生极大的影响,因为事物必须按顺序运行,在实际开发中,为了提升性能,事物会以较低的隔离级别运行,事物隔离级别可以通过隔离事物属性指定。
事物的并发问题
1)脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据。
2)不可重复读:事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果因此本事务 先后两次读到的数据结果会不一致。
3)幻读:幻读解决了不重复读,保证了同一个事务里,查询的结果都是事务开始时的状态(一致性)。
事物隔离级别
1)读未提交:另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据脏读。
2)不可重复读:事务A多次读取同一数据,事务B在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果因此本 事务先后两次读到的数据结果会不一致。
3)可重复读:在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象。
4)串行化:最高的隔离级别,在这个隔离级别下,不会产生任何异常。并发的事务,就像事务是在一个个按照顺序执行一样。
MySQL默认的事务隔离级别为repeatable-read。
1)InnoDB支持事务,MylSAM不支持,这一点是非常之重要。事务是一种高级 的处理方式,如在一些列増删改中只要哪个岀错还可以回滚还原,而MylSAM 就不可以了。
2)MylSAM适合查询以及插入为主的应用。InnoDB适合频繁修改以及涉殛安全性较高的应用。
3)InnoDB支持外键,MylSAM不支持。
4)从MySQL5.5.5以后,InnoDB是默认引擎。
5)InnoDB不支持FULLTEXT类型的索引。
6)InnoDB 中不保存表的行数,如 selectcount(*)fromtable 时,InnoDB 需要 扫描一遍整个表来计算有多少行,但是MylSAM只要简单的读岀保存好的行数即可。注意的是,当count(*)语句包含where条件时MylSAM也需要扫描 整个表。
7)对于自増长的字段,InnoDB中必须包含只有该字段的索引,但是在MylSAM 表中可以和其他字段一起建立联合索引。
8)DELETE FROM TABLE时,InnoDB不会重新建立表,而是一行一行的删除,效率非常慢。MylSAM则会重建表。
9)InnoDB支持行锁(某些情况下还是锁整表,如update table set a=1 where user like %lee%’。
1)临时表可以手动删除:DROP TEMPORARY TABLE IF EXISTS temp_tb;
2)临时表只在当前连接可见,当关闭连接时,MySQL会自动删除表并释放所有空 间。因此在不同的连接中可以创建同名的临时表,并且操作属于本连接的临时表。
3)创建临时表的语法与创建表语法类似,不同之处是増加关键字TEMPORARY, 如:
CREATE TEMPORARY TABLE tmp\_table (
NAME VARCHAR (10) NOTNULL,
time date NOT NULL
select \* from tmp\_table;
1)INNODB会支持一些关系数据库的高级功能,如事务功能和行级锁,MylSAM不支持。
2)MylSAM的性能更优,占用的存储空间少,所以,选择何种存储引擎,视具体应用而定。
3)如果你的应用程序一定要使用事务,毫无疑问你要选择INNODB引擎。但要注意,INNODB的行级锁是有条件的。在where条件没有使用主键时,照样会锁全表。比如DELETE FROM mytable这样的删除语句。
4)如果你的应用程序对查询性能要求较高,就要使用MylSAM了。MylSAM索 引和数据是分开的,而且其索引是压缩的,可以更好地利用内存。所以它的查询性能明显优于INNODB。压缩后的索引也能节约一些磁盘空间。MylSAM拥有全文索引的功能,这可以极大地优化LIKE查询的效率。
1)Hash索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位;
2)B+树索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访冋;
注:BAT面试常问,为什么不用Hash索引而还要使用B+树索引呢?
Hash索引
1)Hash索引仅仅能满足"=",“IN”和”"查询,不能使用范围查询,因为经过相应 的Hash算法处理之后的Hash值的大小关系,并不能保证和Hash运算前完全—样;
2)Hash索引无法被用来避免数据的排序操作,因为Hash值的大小关系并不一定和Hash运算前的键值完全一样;
3)Hash索引不能利用部分索引键查询,对于组合索引,Hash索引在计算Hash 值的时候是组合索引键合并后再一起计算Hash值,而不是单独计算Hash 值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash索引也无法被利用;
4)Hash索引在任何时候都不能避免表扫描,由于不同索引键存在相同Hash 值,所以即使取满足某个Hash键值的数据的记录条数,也无法从Hash索引中直接完成查询,还是要回表查询数据;
5)Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B+树索引高。存储Hash冲突
B+Tree索引:
1)MySQL中,只有HEAP/MEMORY引擎才显示支持Hash索引。
2)常用的InnoDB引擎中默认使用的是B+树索引,它会实时监控表上索引的使用情 况,如果认为建立哈希索引可以提高查询效率,则自动在内存中的“自适应哈希索 引缓冲区”建立哈希索引(在InnoDB中默认开启自适应哈希索引),通过观察搜 索模式,MySQL会利用index key的前缀建立哈希索引,如果一个表几乎大部分都 在缓冲池中,那么建立一个哈希索引能够加快等值查询
B+树索引和哈希索引的明显区别是:
1)如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法 即可找到相应的键值;这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该撻所在位置,然后再根据S表往后扫描,直到找到相应 的麴居;
如果是范围查询检索,这时候哈希素引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成 范围查询检索;
2)哈希索引没办法利用索引完成排序,以及like,xxx%,这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);
3)哈希索引也不支持多列联合索引的最左匹配规则;
4)B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问 题。
5)在大多数场景下,都会有范围查询、排序、分组等查询特征,用B+树索引就可以了
根本区别
聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致。
聚集索引
1)聚集索引表记录的排列顺序和索引的排列顺序一致(所以查询效率快,只要找到第一个索引值记录,其余就连续性的记录在物理也一样连续存放。聚集索引对应 的缺点就是修改慢,因为为了保证表中记录的物理和索引顺序一致,在记录插入 的时候,会对数据页重新排序。
2)聚集索引类似于新华字典中用拼音去查找汉字,拼音检索表于书记顺序都是按照 a~z排列的,就像相同的逻辑顺序于物理顺序一样,
非聚集索引
1)非聚集索引制定了表中记录的逻辑顺序,但是记录的物理和索引不一定一致,两种索引都采用B+树结构,非聚集索引的叶子层并不和实际数据页相重叠,而采用 叶子层包含一个指向表中的记录在数据页中的指针方式。非聚集索引层次多,不会造成数据重排。非聚集索引类似在新华字典上通过偏旁部首来查询汉字,检索表也许是按照横、 竖、撇来排列的,但是由于正文中是a~z的拼音顺序,所以就类似于逻辑地址于物理地址的不对应。
2)适用的情况就在于分组,大数目的不同值,频繁更新的列中,这些情况即不适合聚集索引。
1)slowquerylog慢查询开启状态。
2)slowquerylog_file慢查询日志存放的位置(这个目录需要MySQL的运行帐 号的可写权限,_般设置为MySQL的数据存放目录)。
3)longquerytime查询超过多少秒才记录。
1)分库分表:水平分库分表,由单点分布到多点数据库中,从而降低单点数据 库压力。
2)集群方案:解决DB宕机带来的单点DB不能访问问题。
3)读写分离策略:极大限度提高了应用中Read数据的速度和并发量。无法解决高写入压力。
key太长会导致一个页当中能够存放的key的数目变少,间接导致索引树的页数目变多,索引层次増加,从而影响整体查询变更的效率。
恢复到任意时间点以定时的做全量备份,以及备份増量的binlog 日志为前提。恢 复到任意时间点首先将全量备份恢复之后,再此基础上回放増加的binlog直至指定的时间点。
1)半同步复制
从MySQL5.5开始,MySQL已经支持半同步复制了,半同步复制介于异步复制和同步复制之间,主库在执行完事务后不立刻返回结果给客户端,需要等待至少一个 从库接收到并写到relay log中才返回结果给客户端。相对于异步复制,半同步复 制提高了数据的安全性,同时它也造成了一个TCP/IP往返耗时的延迟。
2)主库配置syncbinlog=1 ,innodbflushlogattrxcommit=1
syncbinlog的默认值是0, MySQL不会将binlog同步到磁盘,其值表示每写多少binlog同步一次磁盘,
innodbflushlogattzxcommit为1表示每一次事务提交或事务外南指令都需要把日志 flush到磁盘。
3)优化网络。升级Slave硬件配置。升级5.7釆用并行复制
1)可以做表拆分,减少单表字段数量,优化表结构。
2)在保证主键有效的情况下,检查主键索引的字段顺序,使得查询语句中条件的 字段顺序和主键索引的字段顺序保持一致。
3)在单表的条件下,SQL语句、行索引优化等,从而提升数据的检索速度。
1)悲观锁
2)FIFO (First Input First Output,先进先岀)缓存队列思路
3)使用乐观锁
1)数据库的数据结构有:非线性数据结构、树形数据结构,集合数据结构
2)数据结构釆用二维表(非线性数据结构)存储。
3)二维表与关系
关系-二维表;
元组-二维表中的行
分量-二维表中的列
4)B+Tree索引–树形数据结构 Hash索引–集合数据结构
注:四种基本的数据结构。线性数据结构(元素之间一对一的关系)结 构又细分为,数组,链表,队列,堆栈。),树形数据结构(比如二叉树,平衡二叉树,B+树),集合数据结构,图形数据结构
1)数据的索引实现为B+Tree、hash索引结构存储数据。
2)B+Tree是一种多路平衡查询树,所以他的节点是天然有序的(左子节点小于父 节点、父节点小于右子节点),所以对于范围查询的时候不需要做全表扫描。
3)Hash索引底层是哈希表,哈希表是一种以key-value存储数据的结构,所以多个数据在存储关系上是完全没有任何顺序关系的。
好了各位,以上就是这篇文章的全部内容了,能看到这里的人呀,都是人才。之前说过,PHP方面的技术点很多,也是因为太多了,实在是写不过来,写过来了大家也不会看的太多,所以我这里把它整理成了PDF和文档,如果有需要的可以
点击进入暗号: PHP+「平台」
更多学习内容可以访问【对标大厂】精品PHP架构师教程目录大全,只要你能看完保证薪资上升一个台阶(持续更新)
以上内容希望帮助到大家,很多PHPer在进阶的时候总会遇到一些问题和瓶颈,业务代码写多了没有方向感,不知道该从那里入手去提升,对此我整理了一些资料,包括但不限于:分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6,laravel,YII2,Redis,Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家,需要的可以加入我的 PHP技术交流群