网站开发用哪个linux,长春网站制作建设,西安大雁塔在哪个区,昆明网站制作网页InnoDB中ACID的实现
先说一下原子性是怎么实现的。 事务要么失败#xff0c;要么成功#xff0c;不能做一半。聪明的InnoDB#xff0c;在干活儿之前#xff0c;先将要做的事情记录到一个叫undo log的日志文件中#xff0c;如果失败了或者主动rollback#xff0c;就可以通… InnoDB中ACID的实现
先说一下原子性是怎么实现的。 事务要么失败要么成功不能做一半。聪明的InnoDB在干活儿之前先将要做的事情记录到一个叫undo log的日志文件中如果失败了或者主动rollback就可以通过undo log的内容将事务回滚。
那undo log里面具体记录了什么信息呢 undo log属于逻辑日志它记录的是sql执行相关的信息。当发生回滚时InnoDB会根据undo log的内容做与之前相反的工作使数据回到之前的状态
那隔离性怎么实现呢 MySQL能支持Repeatable Read这种高隔离级别主要是锁和MVCC一起努力的结果。 我先说锁吧。事务在读取某数据的瞬间必须先对其加行级共享锁直到事务结束才释放事务在更新某数据的瞬间必须先对其加行级排他锁直到事务结束才释放 为了防止幻读还会有间隙锁进行区间排它锁定。 然后是MVCC多版本并发控制主要是为了实现可重复读虽然锁也可以但是为了更高性能考虑使用了这种多版本快照的方式。 因为是快照所以一个事务针对同一条Sql查询语句的结果不会受其它事务影响。
MySQL为什么用树做索引 一般而言能做索引的要么Hash要么树要么就是比较特殊的跳表。Hash不支持范围查询跳表不适合这种磁盘场景而树支持范围查询且多种多样很多树适合磁盘存储。所以MySQL选择了树来做索引。
MySQL锁的分类吧。 MySQL从锁粒度粒度上讲有表级锁、行级锁。从强度上讲又分为意向共享锁、共享锁、意向排它锁和排它锁。 间隙锁就是对索引行进行加锁操作不仅锁住其本身还会锁住周围邻近的范围区间。间隙锁的目的是为了解决幻影读但也因此带来了更大的死锁隐患。 比如一个任务表里面有个状态字段是一个非唯一索引有一个任务id是唯一索引。 一个sql将状态处于执行中的任务设置为等待中另一个sql正好通过任务id更新在范围内的一条任务信息。那么因为是在不同索引加锁的所以都能成功。但是最后去更新主键数据的时候就会死锁。
那要怎么找到MySQL执行慢的语句呢 我们可以看慢查询日志它是MySQL提供的一种日志记录用来记录在MySQL中响应时间超过阀值的语句这个阈值通常默认为10s也可以按需配置。 Mysql是默认关闭慢查询日志的所以需要我们手动开启。set global slow_query_log1
那找到慢语句之后怎么查看它的执行计划 使用explain命令它可以获取到MySQL语句的执行计划 包括会使用的索引、扫描行数、表如何连接等信息。 通过这个命令我们很容易就看出一条语句是否使用了我们预期的索引并进行相应的调整。 MySQL如果查询压力太大该怎么办 如果SQL语句已经足够优秀。那么就看请求压力是否符合二八原则也就是说80%的压力都集中在20%的数据。 如果是我们可以增加一层缓存常用的实现是在MySQL前加个Redis缓存。当然如果实在太大了那么只能考虑分库分表啦。
如果是写入压力太大呢 写缓冲。一般而言可以增加消息队列来缓解。这样做有两个好处一个是缓解数据库压力第二个可以控制消费频率。
如果发现线上Insert导致cpu很高你会怎么解决 1.查看是不是请求量突然飙升导致如果是攻击则增加对应的防护 2.查看是否因为数据规模达到一个阈值导致MySQL的处理能力发生了下降 3.查看二级索引是否建立过多这种情况需要去清理非必要索引。
Count操作的性能怎么优化 第一种是用Redis缓存来计数。每次服务启动就将个数加载进Redis这种方案适用于对数据精确度要求不是特别高的场景。 第二种为count的筛选条件建立联合索引。这样可以实现索引覆盖在二级索引表中就可以得到结果不用再回表回表可是O(n)次随机I/O呢。这种方案适用于有where条件的情况并且与其它方案不冲突可共同使用。 第三种可以多维护一个计数表通过事务的原子性维持一个准确的计数。这种方案适用于对数据精度高读多写少场景。你对MySQL分表有了解吗 随着业务持续扩张单表性能一定会达到极限分表是把一个数据库中的数据表拆分成多张表通过分布式思路提供可扩展的性能。 那你做过的项目中分表逻辑怎么实现的 分表逻辑一定是在一个公共的可复用的位置来实现。我之前做的项目是实现了一个本地依赖包即将分表逻辑写在公共的代码库里每个需要调用服务的客户方都集成该公共包就接入了自动分表的能力。 优点在于简单不引入新的组件不增加运维难度。缺点是公共包更改后每个客户端都需要更新。 如果初期没做分表已有3000W数据此时要分库分表怎么做 最复杂的情况持续比较大的访问流量下并且要求不停服。我们可以分几个阶段来操作 1. 双写读老阶段通过中间件对write sql同时进行两次转发也就是双写保持新数据一致同时开始历史数据拷贝。本阶段建议施行一周 2. 双写双读阶段采用灰度策略一部分流量读老表一部分流量读新表读新表的部分在一开始还可以同时多读一次老表数据进行比对检查观察无误后随着时间慢慢切量到新表。本阶段建议施行至少两周 3. 双写读新阶段此时基本已经稳定可以只读新表为了安全保证建议还是多双写一段时间防止有问题遗漏。本阶段建议周期一个月 4. 写新读新阶段此时已经完成了分表的迁移老表数据可以做个冷备MySQL都有哪些锁举出所有例子各个锁的作用是什么区别是什么 1.从数据操作的类型分类 共享锁S锁也称为读锁对于其他事务而言是可读不可写的。多个事务可以同时持有共享锁并且共享锁之间不会互斥。 排他锁X锁也称写锁对于其他事务而言是不可读也不可写的确保在多个事务中对同一资源只有一个事务能写入并防止其他用户读取正在写入的资源。 2.从锁的粒度分类2.1 表锁Table Lock 锁定整张表。表锁又可分为表级别的S锁和X锁、意向锁、元数据锁、自增锁 2.11 表级别的S锁和X锁 一般情况下不会使用到InnoDB中提供的表级别的S锁和X锁只会在一些特殊情况下比方说崩溃恢复过程中用到而在MyISM比较常用。 2.1.2 意向锁 假如有事务T1和T2T1获取了某表中最后一行记录的行锁S锁此时T2想加表锁X锁这是不允许的S锁和X锁互斥但是T2并不知道该表有没有加过行锁需要一行一行的去检查直到最后一行效率非常低。但是如果有意向锁的话T1获取行锁时会额外加上表级别的意向锁告诉其他事务该表已经有人加过锁了。此时T2只需要检查该表上是否有意向锁即可。 意向锁的作用就是加快表锁的检查过程。 意向锁是由存储引擎自己维护的 用户无法手动获取在为数据行加共享/排他锁之前InooDB会先获取该数据所在表的对应意向锁。意向锁可分为 ●意向共享锁IS事务有意向对表中的某些行加共享锁S锁会自动加上意向共享锁 ●意向排他锁IX事务有意向对表中的某些行加排他锁X锁会自动加上意向排它锁 2.1.3 自增锁 表中有自增列时插入记录会使用到自增锁一个事务持有自增锁时其他事务的插入语句会被阻塞。了解即可。 2.1.4 元数据锁 在对某个表执行一些诸如ALTER TABLE 、DROP TABLE这类的DDL语句时其他事务对这个表并发执行诸如SELECT、INSERT、DELETE、UPDATE的语句会发生阻塞。同理某个事务中对某个表执行SELECT、INSERT、DELETE、UPDATE语句时在其他事务中对这个表执行DDL语句也会发生阻塞。这个过程其实是通过在server层使用一种称之为元数据锁英文名 Metadata Locks 简称 MDL结构来实现的。 MDL主要是为了避免DML和DDL冲突保证读写的正确性。2.2 行锁 2.21 记录锁Record Locks 记录锁就是行级别的X锁和S锁仅仅锁住一行记录分S型记录锁和X型记录锁 2.22 间隙锁Gap Locks gap锁的提出仅仅是为了防止插入幻影记录而提出的没有额外其他功能。 2.23 临键锁Next-Key Locks InnoDB默认的锁就是Next-Key locks。 临键锁 记录锁 间隙锁 在可重复读隔离级别下默认加的行锁就是临键锁防止幻读。但是有些时候InnoDB会将它优化为记录锁或间隙锁 2.3全局锁 全局锁就是对整个数据库实例加锁。当你需要让整个库处于只读状态的时候可以使用这个命令主要是做全库逻辑备份备份时应该锁定整个库保证数据的完整性。3.从锁的态度分类 分为悲观锁和乐观锁。需要注意的是乐观锁和悲观锁并不是锁而是锁的设计思想 。 1.悲观锁Pessimistic Locking 假设最坏的情况每次操作数据都会加上锁如行锁、表锁等都是在做操作之前先上锁当其他线程想要访问数据时都需要阻塞挂起。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。 2.乐观锁Optimistic Locking 乐观锁认为对同一数据的并发操作不会总发生属于小概率事件不用每次都对数据上锁它不采用数据库自身的锁机制而是通过程序来实现。 在程序上我们可以采用版本号机制或者CAS机制实现。乐观锁适用于多读和冲突不激烈的应用类型这样可以提高吞吐量。在Java中通过CAS实现的。 4.死锁 ●直接进入等待直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。 ●发起死锁检测发现死锁后主动回滚死锁链条中的某一个事务让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on 表示开启这个逻辑。
一条sql更新的执行流程
1.通过连接器建立连接
2.解析SQL语句执行计划交给执行器执行
3.从磁盘加载page页到内存的buffer pool
4.记录undolog日志用于mvcc和回滚操作
5.更新buffer pool的数据记录page页的更改
6.写入redo log把redo log状态记为prepare
7.记录bin log逻辑日志用于主从同步和数据备份
8.提交事务将redo log状态改为commit
MySQL的Server和引擎层有什么区别为什么要分层
连接层用户与MYSQL服务进行TCP链接校验用户身份用户权限。
服务层用户写的SQL语句会到服务层进行解析生成语法树。优化SQL语句生成执行计划。
引擎层真正与磁盘进行交互对数据进行存储和读取。
区别
分层架构使得MySQL可以更加容易地扩展新的功能和服务。
MySQL可以更加高效地进行查询处理和事务管理。
MySQL有缓存机制吗buffer pool和change buffer作用是什么
Buffer Pool缓冲池
内存中以页page为单位缓存磁盘数据减少磁盘IO提升访问速度
缓冲池大小默认128M独立的MySQL服务器推荐设置缓冲池大小为总内存的80%。主要存储数据页、索引页更新缓冲change buffer等
Change Buffer写缓冲
如果每次写操作数据库都直接更新磁盘中的数据会很占磁盘IO。为了减少磁盘IO
InnoDB在Buffer Pool中开辟了一块内存用来存储变更记录为了防止异常宕机丢失缓存
当事务提交时会将变更记录持久化到磁盘redo log等待时机更新磁盘的数据文件刷脏
用来缓存写操作的内存就是Change Buffer
Change Buffer默认占Buffer Pool的25%最大设置占用50%
