Mysql-存储引擎问题

问题一: 说一说你了解的 Mysql 存储引擎及其适用的场景???

• mysql 常用的引擎

  • myisam: 不支持事务, mysql5.6 之前默认的引擎, 最常用的非事务存储引擎

    • 以堆表方式存储, 无序, 表级锁, 读写操作相互堵塞; 不适合高并发的场景, 适合读操作远大于写操作

    • 支持 Btree, 空间, 全文索引

    • check table myIsam; 检查 myisam 表; 查看是否出现损坏

    • repair table myIsam; 这样的表索引表会出现问题, 这样可以修复

    • myisampack -b -f myIsam; 压缩表文件

  • CSV: 以 CSV 格式存储的非事务型存储引擎, general_log 表就是使用的这种存储引擎方式

    • 所有的列都不能为 null; 不支持索引

    应用场景: 作为数据交换的中间表使用,

  • Archive: 不支持事务, 只允许查询和新增数据而不允许修改的非事务型存储引擎

    • 表数据使用 zlib 压缩, 节约存储空间, 比 myisam 小 75%, 比 InnoDB 小 25%

    • 只支持 Insert 和 Select

    • 只可以在自增的 ID 上新建索引, 不能在其他列上增加索引

    日志和数据采集类的应用, 数据归档存储,

  • Memory: 一种读写快速;存储在内存中的非事务性的存储引擎

    • 所有字段长度固定

    • 支持 Btree, 和 Hash 索引

    用于缓存字典映射表, 缓存周期性分析数据

  • InnoDB: 一种常用的事务型存储引擎, 5.6 之后是默认的引擎

    • 支持 ACID 操作

    • 数据按主键聚集存储, 主键的大小会影响到索引的查询效率

    • 支持行级锁及MVCC

    • 支持 BTree 和自适应 Hash 索引

    • 支持全文和空间索引 5.7 以上支持

    大多数 OLTP 场景

  • NDB: mysql 集群所使用的内存型事务存储的引擎

    • 支持行级锁, 支持高可用集群, 支持 Ttree 索引

    需要数据完全同步的高可用场景

问题二: 在什么情况下,InnoDB 无法在线修改表结构???

• InnoDB 不支持在线修改表结构的场景

  • 添加全文索引, create fulltext index name on table(colum);

  • 添加空间索引; alter table geom add spatial index(g);

  • 删除主键: alter table table_name drop primary key;

  • 增加自增列: alter table table_name add column id int auto_increment not null primary key;

  • 修改列类型: alter table table_name change c1 c2 new_type

  • 修改表字符集: alter table tab_name character set = 'character_name';

问题三: 在无法进行在线修改表 结构的情况下, 要如何操作???

• 在线 DDL 存在的问题

  • 有部分语句不支持在线 DDL

  • 长时间的 DDL 操作会引起严重的主从延迟

  • 无法对 DDL 操作进行资源限制

• 如何更加安全的执行 DDL ??

  • pt-online-schema-change [options] DSN; 使用这个工具, 使用一个新表来覆盖原先的表;

    • 使用: pt-online-schema-change --alter='add column column_name timestamp' --execute D=database, t=table_name, u=root, p=xxxx

问题四: InnoDB 是如何实现事务 ???

• 事务: 一组要执行的 sql; 要么都成功, 要么失败; 这组 sql 可是一条; 也可以是多条;

  • 原子性(A): 一个事务中的所有的操作, 要么全部完成, 要么不完成, 不会结束在中间某个环节

  • 一致性(C): 在事务开始之前和事务结束之后, 数据库的完整性没有被破坏

  • 隔离性(I): 事务的隔离性要求每个读写事务的对象与其他事务的操作对象能相互分离, 即该事务提交之前对其他事务都不可见

  • 持久性(D): 事务一旦提交了, 其结果就是永久性的, 就算发生了故障事故, 数据库也能将数据恢复;

• 四个特性的实现方式:

  • 原子性: 使用回滚日志(Undo log): 用于记录数据修改前的状态

  • 一致性: 重作日志(Redo log): 用于记录数据修改后的状态

  • 隔离性: 锁: 用于资源隔离; 共享锁和排他锁, 相互互斥

  • 持久性: Redo log + Undo log 实现

问题五: InnoDB 读操作是否会阻塞写操作 ???

• 查询需要对资源会添加 共享锁(S)

• 数据修改需要对资源加排它锁 (X)

• 排它锁和排它锁是不兼容的; 但是共享锁和共享锁是兼容的

• 客户端的 update 不会阻塞 select 操作;

MVCC(多版本并发控制)实现:

-通过 Undo log 和 Redo log 来实现;