InnoDB

三张表：user article blog 表的存储sql文件： /* Navicat MySQL Data Transfer Source Server : localhost Source Server Version : 50620 Source Host : localhost:3306 Source Database : mybatis Target Server Type : MYSQL Target Server Version : 50620 File Encoding : 65001 Date: 2014-10-19 18:27:31 */ SET FOREIGN_KEY_CHECKS=0; -- ---------------------------- -- Table structure for `user` -- ---------------------------- DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userName` varchar(50) DEFAULT NULL, `userAge` int(11) DEFAULT NULL, `userAddress` varchar(200) DEFAULT NULL

点击上方“ 掌上编程 ”，选择“ 置顶或者星标 ” 优质文章第一时间送达！ 来源：r6a.cn/bZSY 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一，单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处？ 本篇博客我们就来分析这个问题,探讨一下内部的原因。 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变. 根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样，然后测试一下表的插入速度和查询速度： 注：这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串18位长度的long值 id自动生成表： 用户uuid表 随机主键表： 1.2.光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试： 技术框架：springboot+jdbcTemplate+junit+hutool,程序的原理就是连接自己的测试数据库,然后在相同的环境下写入同等数量的数据

20个数据库常见面试题讲解() 进了互联网公司，整天也就是搬砖，等到了面试的时候，发现数据库方面，忘得一塌糊涂，抽时间整理了一些数据库方面的题。欢迎大家向我推荐你在面试过程中遇到的问题,我会把大家推荐的问题添加到下面的常用面试题清单中供大家参考。 1.事务四大特性（ACID）原子性、一致性、隔离性、持久性？ 2.事务的并发？事务隔离级别，每个级别会引发什么问题，MySQL默认是哪个级别？ 3.MySQL常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别？ 4.MySQL的MyISAM与InnoDB两种存储引擎在，事务、锁级别，各自的适用场景？ 5.查询语句不同元素（where、jion、limit、group by、having等等）执行先后顺序？ 6.什么是临时表，临时表什么时候删除? 7.MySQL B+Tree索引和Hash索引的区别？ 8.sql查询语句确定创建哪种类型的索引？如何优化查询？ 9.聚集索引和非聚集索引区别？ 10.有哪些锁（乐观锁悲观锁），select 时怎么加排它锁？ 11.非关系型数据库和关系型数据库区别，优势比较？ 12.数据库三范式，根据某个场景设计数据表？ 13.数据库的读写分离、主从复制，主从复制分析的 7 个问题？ 14.使用explain优化sql和索引？ 15.MySQL慢查询怎么解决？ 16.什么是 内连接、外连接

MySQL 8.0新增特性 use_invisible_indexes：是否使用不可见索引，MySQL 8.0新增可以创建invisible索引，这一开关控制优化器是否使用invisible索引，on表示考虑使用。 MySQL 5.7新增 derived_merge：派生表合并，类似Oracle的视图合并，当派生SQL中存在以下操作是无法展开UNION 、GROUP 、DISTINCT、LIMIT及聚合操作 duplicateweedout：是否使用使用临时表对semi-join产生的结果集去重 condition_fanout_filter：cost模型在jion 代价计算时考虑condition,是否还要还要考虑condition上的filter，如果是on表示考虑 MySQL 5.6 新增 mrr和mrr_cost_based：针对多列索引，也叫组合索引来做基本扫描，然后对匹配的记录按照主键排序，这样按照有序的主键顺序从磁盘上扫描需要的全部记录。根本功能是把对磁盘的随机扫描转化为顺序扫描。 batched_key_access：对于多表join语句，当MySQL使用索引访问第二个join表的时候，使用一个join buffer来收集第一个操作对象生成的相关列值。BKA构建好key后，批量传给引擎层做索引查找。key是通过MRR接口提交给引擎的. 这样，MRR使得查询更有效率。

程序员的成长之路 互联网/程序员/技术/资料共享 关注 阅读本文大概需要 5.6 分钟。 作者：Yrion cnblogs.com/wyq178/p/12548864.html 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一，单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处？ 本篇博客我们就来分析这个问题,探讨一下内部的原因。 本篇博客的目录 mysql程序实例 使用uuid和自增id的索引结构对比 总结 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变. 根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样，然后测试一下表的插入速度和查询速度： 注：这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串18位长度的long值 id自动生成表： 用户uuid表 随机主键表： 1.2.光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试： 技术框架

来源：程序猿面试指南 既然这块知识点不清楚，那回头就自己动手实践下。 首先，创建一个最简单的表，只包含一个自增 id，并插入一条数据。 create table t0(id int unsigned auto\_increment primary key) ;insert into t0 values(null); 通过 show 命令 show create table t0; 查看表情况 CREATE TABLE \`t0\` ( \`id\` int(10) unsigned NOT NULL AUTO\_INCREMENT, PRIMARY KEY (\`id\`)) ENGINE=InnoDB AUTO\_INCREMENT=2 DEFAULT CHARSET=utf8 可以发现 AUTO_INCREMENT 已经自动变成 2，这离用完还有很远，我们可以算下最大当前声明的自增 ID 最大是多少，由于这里定义的是 intunsigned ，所以最大可以达到 2 的 32 幂次方 - 1 = 4294967295 这里有个小技巧，可以在创建表的时候，直接声明 AUTO_INCREMENT 的初始值 create table t1(id int unsigned auto\_increment primary key) auto\_increment = 4294967295

测试环境： 主节点：81.69.247.195 从节点：124.71.182.20 linux：centos6.5 主: 1. 编辑 vim /etc/my.cnf 添加：log-bin = mysql-bin 添加 :server-id =1 添加：innodb-file-per-table =ON 添加：skip_name_resolve=ON 2. 重启mysql：service mysqld restart 3.进入mysql：mysql -u root -p 4.查看二进制信息： show global variables like '%log%'; 5.查看主节点二进制日志列表 show master logs; 6.查看主节点的server id show global variables like '%server%'; 7.在主节点上创建有复制权限的用户。REPLIACTION SLAVE ，REOPLIATION CLIENT grant replication slave,replication client on *.* to 'admin'@'124.71.182.20' identified by '123456'; 8.刷新 flush privileges; 从： 1. 编辑 vim /etc/my.cnf 添加：relay-log=relay

MySQL日志分类 　　MySQL日志主要包含：错误日志、查询日志、慢查询日志、重做日志、回滚日志、二进制日志 错误日志： 　　用来记录 MySQL 服务器运行过程中的错误信息，比如，服务器启动关闭信息、运行错误信息、时间调度器运行一个事件时产生的信息、在服务器上启动进程产生的信息。 　　错误日志可以自己配置，log-error：配置是否启用错误日志功能和错误日志的存储位置、log-warning：配置是否将警告信息也定义至错误日志中 　　错误日志存储在数据库的数据文件目录中，名称为 hostname.err，其中 hostname 为服务器主机名。在 MySQL 5.5.7 之前，数据库管理员可以删除很长时间之前的错误日志，以节省服务器上的硬盘空间， MySQL 5.5.7 之后，服务器将关闭此项功能，只能使用重命名原来的错误日志文件，手动冲洗日志创建一个新的。命令为： mv hostname.err hostname.err.old mysqladmin flush-logs 查询日志： 　　查询日志在 MySQL 中被称为 general log(通用日志)，查询日志里的内容不要被“查询日志”误导，认为里面只存储 select 语句，其实不然，查询日志里面记录了数据库执行的所有命令，不管语句是否正确，都会被记录，具体原因如下: insert 查询为了避免数据冲突

常见的mysql存储引擎有MyISAM，InnoDB 1.存储引擎MyISAM 　　（1）它不支持事务，也不支持外键，尤其是访问速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表 　　（2）每个MyISAM在磁盘上存储成3个文件，其中文件名和表名都相同，但是扩展名分别为： 　　　　.frm（表结构信息） 　　　　MYD（MYData，数据信息） 　　　　MYI（MYIndex，索引信息） 　　特性： 　　　　并发性与锁级别：表级锁（并发性差，对只读还可以） 表损坏修复：check table tableName; repair table tableName 　　支持的索引类型 　　支持数据压缩：myisampack –b –f myIsam.MYI命令（对已经压缩的表不能进行写操作） 　　限制： 　　使用场景：非事务型应用（非财务应用）；只读类应用（报表应用）；空间类应用（空间函数jps等） 2.存储引擎InnoDB 　　（1）Innodb使用表空间进行数据存储 　　　　使用表空间配置参数：innodb_file_per_table 　　　　ON：每一个独立表空间：tablename.ibd； 　　　　OFF：系统表空间：ibdataX 　　　　系统表空间和独立表空间如何选择： 　　　　比较： 　　　　1

《InnoDB，5项最佳实践，知其所以然？》发布后，不少同学留言希望讲讲MySQL的InnoDB行锁机制。要细聊MySQL的行锁，难以避免的要从事务的四种隔离级别说起。 四种隔离级别，又脱不开聊读脏，不可重复读，读幻象等问题。 事务隔离级别，行锁机制等都比较垂直，应用开发中大部分同学都用不到，不确定是否大部分朋友都感兴趣。 今天，先抛出一个问题，如果大家确定对这类话题感兴趣的话，后续我花时间细聊这一系列问题。 MySQL默认的事务隔离级别是 Repeated Read (RR)，假设使用的存储引擎是InnoDB，在这个隔离级别下： （1）读取到数据，都是其他事务已提交的数据； （2）同一个事务中，相同的连续读，得到的结果应该是相同的； （3）不会出现insert幻象读； 假设有数据表： t(id int PK, name); 假设目前的记录是： 10, shenjian 20, zhangsan 30, lisi Case 1 事务A先执行，并且处于未提交状态： update t set name=’a’ where id=10; 事务B后执行： update t set name=’b’ where id=10; 因为事务A在PK id=10上加了行锁，因此事务B会阻塞。 Case 2 事务A先执行，并且处于未提交状态： delete from t where id=40;