InnoDB

一、案例分享 1.1 问题描述 以下一例报错是开发同学通过框架初始化创建一些表结构时出现的报错，我们需要重点关注“1071 Specified key was too long; max key length is 7671071 Specified key was too long; max key length is 767 bytes”这个提示。该报错告诉我们索引长度超过的额767，因过长而无法创建索引。这也是为什么经常在一些MySQL的SQL审批中，DBA同学会经常要求某个表的字段长度尽量不要超过191、某些表的字段长度不要超过255。 Fatal error: Uncaught PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes in /var/www/html/includes/vendor/aura/sql/src/ExtendedPdo.php:748 Stack trace: #0 /var/www/html/includes/vendor/aura/sql/src/ExtendedPdo.php(748): PDOStatement->execute() #1

一、对MySQL的锁的了解 当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。 就像酒店的房间，如果大家随意进出，就会出现多人抢夺同一个房间的情况，而在房间上装上锁，申请到钥匙的人才可以入住并且将房间锁起来，其他人只有等他使用完毕才可以再次使用。 二、隔离级别与锁的关系 在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突 在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁。 在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁。 SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。 三、按照锁的粒度分数据库锁有哪些？ 锁机制与InnoDB锁算法 在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎)、表级锁(MYISAM引擎)和页级锁(BDB引擎 )。 MyISAM和InnoDB存储引擎使用的锁： MyISAM采用表级锁(table-level locking)。 InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁。 行级锁，表级锁和页级锁对比

爱因斯坦说过“耐心和恒心总会得到报酬的”，我也一直把这句话当做自己的座右铭，这句箴言在今年也彻底在我身上实现了。 每一个程序员都拥有一座大厂梦，我也不例外，去年面试阿里P6，竟然被MySQL问倒了，很多相关性的问题都没有答上来，才2面就凉凉了。回去之后也潜心复习了，准备了二战，如今终于进入了阿里，被天猫团队录用。 01 阿里面试题之MySQL 请解释关系型数据库概念及主要特点？ 请说出关系型数据库的典型产品、特点及应用场景？ 请详细描述 SQL 语句分类及对应代表性关键字。 什么是 MySQL 多实例，如何配置 MySQL 多实例？ 如何加强 MySQL 安全，请给出可行的具体措施？ 误操作执行了一个 drop 库 SQL 语句，如何完整恢复？ 详述 MySQL 主从复制原理及配置主从的完整步骤。 MySQL 如何实现双向互为主从复制，并说明应用场景？ MySQL 如何实现级联同步，并说明应用场景？ MySQL 主从复制故障如何解决？ 02 二战阿里，天猫团队面试题（3轮技术面+HR面） 阿里面试技术题： 自我介绍呗 项目介绍呗（先自己介绍项目，然后再聊天） junit用法，before，beforeClass，after，afterClass的执行顺序 分布式锁 nginx的请求转发算法，如何配置根据权重转发 用hashmap实现redis有什么问题（死锁，死循环

1.事务的特性 1.原子性：一个事务必须被视为一个不可分割的最小工作单元；事务的操作，要么全部成功，要么全部失败。 2.一致性：数据库总是从一个一致性的状态转换到另一个一致性的状态。 3.隔离性：通常来说，一个事务所作的操作在最终提交之前，对其他事务是不可见的。 4.持久性：一旦事务提交，则所作的修改就会永久的保存到数据库中。 2.事务的隔离级别 1.未提交读：事务的修改，即使没有提交，对其他事务也都是可见的。（有脏读可能性） 2.已提交读：一个事务从开始直到提交之前，所作的任何修改对其他事务都是不可见。（有不可重复读可能性） 3.可重复读：同一个事务多次读取同样的记录是一致的。（有幻读可能性）。MySQL的默认隔离级别，InnoDB采用了MVCC（多版本并发控制）解决了幻读的问题。 4.可串行化：强制事务串行执行，避免幻读。会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁竞争的问题。一般很少用到，效率比较低。 3.死锁 两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源。 4.事务日志 使用事务日志，存储引擎在修改表的数据只需要修改其内存拷贝，再把修改行为记录到事务日志中（事务日志采用的是追加的方式），事务日志持久化以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。修改数据需要写两次磁盘。 5.索引的数据结构 1.B+Tree：所有的值都是按顺序存储

/* Navicat MySQL Data Transfer Source Server : workplace Source Server Version : 50610 Source Host : 127.0.0.1:3306 Source Database : dormdb Target Server Type : MYSQL Target Server Version : 50610 File Encoding : 65001 Date: 2019-08-13 10:29:35 */ create database mydormdb; use mydormdb; SET FOREIGN_KEY_CHECKS=0; -- Table structure for building DROP TABLE IF EXISTS building ; CREATE TABLE building ( buildId int(11) NOT NULL AUTO_INCREMENT, buildName varchar(30) DEFAULT NULL, dormCount int(11) DEFAULT NULL, dormFloor int(11) DEFAULT NULL, PRIMARY KEY ( buildId ) ) ENGINE=InnoDB AUTO_INCREMENT

redo log的大小是固定的，在mysql中可以通过修改配置参数innodb_log_files_in_group和innodb_log_file_size配置日志文件数量和每个日志文件大小，redo log采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。 二进制日志相关内容，参考： MariaDB/MySQL的二进制日志 。 redo log不是二进制日志。虽然二进制日志中也记录了innodb表的很多操作， 也能实现重做的功能， 但是它们之间有很大区别。 二进制日志是在 存储引擎的上层 产生的，不管是什么存储引擎，对数据库进行了修改都会产生二进制日志。而redo log是innodb层产生的，只记录该存储引擎中表的修改。 并且二进制日志先于 redo log 被记录 。具体的见后文group commit小结。 二进制日志记录操作的方法是逻辑性的语句。即便它是基于行格式的记录方式，其本质也还是逻辑的SQL设置，如该行记录的每列的值是多少。而redo log是在物理格式上的日志，它记录的是数据库中每个页的修改。 二进制日志只在每次事务提交的时候一次性写入缓存中的日志"文件"(对于非事务表的操作

1、如何快速掌握MySQL? 培养兴趣 兴趣是最好的老师，不论学习什么知识，兴趣都可以极大地提高学习效率。当然学习MySQL 5.6也不例外。 夯实基础 计算机领域的技术非常强调基础，刚开始学习可能还认识不到这一点，随着技术应用的深入，只有有着扎实的基础功底，才能在技术的道路上走得更快、更远。对于MySQL的学习来说，SQL语句是其中最为基础的部分，很多操作都是通过SQL语句来实现的。所以在学习的过程中，读者要多编写SQL语句，对于同一个功能，使用不同的实现语句来完成，从而深刻理解其不同之处。 及时学习新知识 正确、有效地利用搜索引擎，可以搜索到很多关于MySQL 5.6的相关知识。同时，参考别 人解决问题的思路，也可以吸取别人的经验，及时获取最新的技术资料。 多实践操作 数据库系统具有极强的操作性，需要多动手上机操作。在实际操作的过程中才能发现问题， 并思考解决问题的方法和思路，只有这样才能提高实战的操作能力。 2、如何选择服务器的类型？ MySQL服务器配置窗口中各个参数的含义如下。 【Server Configuration Type】该选项用于设置服务器的类型。单击该选项右侧的向下按钮， 即可看到包括3个选项。 3个选项的具体含义如下： Development Machine(开发机器)：该选项代表典型个人用桌面工作站。假定机器上运行 着多个桌面应用程序

当MySQL单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化： 单表优化 除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在 千万级 以下，字符串为主的表在 五百万 以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量： 字段 尽量使用 TINYINT 、 SMALLINT 、 MEDIUM_INT 作为整数类型而非 INT ，如果非负则加上 UNSIGNED VARCHAR 的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用 TIMESTAMP 而非 DATETIME ， 单表不要有太多字段，建议在20以内 避免使用NULL字段，很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好，要根据查询有针对性的创建，考虑在 WHERE 和 ORDER BY 命令上涉及的列建立索引，可根据 EXPLAIN 来查看是否用了索引还是全表扫描 应尽量避免在 WHERE 子句中对字段进行 NULL 值判断，否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键，由程序保证约束 尽量不用 UNIQUE

　　InnoDB 采用了MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ(可重复读) ，并且，通过间隙锁（next-key locking）策略防止幻读的出现。间隙锁使得InnoDB 不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，防止幻影行的插入。 　　InnoDB 是基于聚簇索引建立的。InnoDB的索引结构和mysql的其他存储引擎有很大的不同，聚簇索引对主键查询有很高的性能。不过它的二级索引（second index，非主键索引）中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应该尽可能的小。INNODB 的存储格式是平台独立的，也就是说可以将数据和索引文件从intel平台复制到power pc或者sun sparc平台。 　　InnoDB 内部做了很多优化，包括从磁盘读取数据时采用的可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引（adaptive hash index），以及能够加速插入操作的插入缓冲区（insert buffer）等。 　　InnoDB 的行为是非常复杂的，不容易理解。如果使用了InnoDB，笔者强烈建议阅读官方手册中的“InnoDB事务模型和锁” 一节。如果应用程序基于InnoDB构建

MySQL 优化 前置问题 数据库连接超时问题？ 数据库查询慢速问题？ 数据库操作阻塞问题？ 解决方案 SQL（索引） 库表结构 系统配置 硬件优化 1 SQL（索引）优化 问题发现 Q：如何发现有问题的 SQL？ A：MySQL 慢查日志。使用 <u>MySQL 慢查日志</u>对有效率问题的 SQL 进行监控。 慢查日志 MySQL 命令 ： # 查看慢查日志是否开启 show variables like 'slow_query_log'; # 开启慢查日志 set global slow_query_log=on; # 查看慢查日志存储位置 show variables like 'slow_query_log_file'; # 指定慢查日志存储位置 set global show_query_log_file='/home/mysql/data/mysql-slow.log'; # 查看记录未使用索引日志是否开启 show variables like 'log_queries_not_using_indexes'; # 开启记录未使用索引日志 set global log_queries_not_using_indexes=on; # 查看慢查时间 show variables like 'long_query_time'; # 指定慢查时间 set global