InnoDB

转载自：http://www.hollischuang.com/archives/934 在 数据库的锁机制 中介绍过，数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。 无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。 针对于不同的业务场景，应该选用不同的并发控制方式。所以， 不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念，更不要把他们和数据中提供的锁机制（行锁、表锁、排他锁、共享锁）混为一谈。其实，在DBMS中，悲观锁正是利用数据库本身提供的锁机制来实现的。 下面来分别学习一下悲观锁和乐观锁。 悲观锁 在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。 悲观并发控制主要用于数据争用激烈的环境

1、longtext==>BLOB 2、boolean==>TINYINT 3、BIT(1)==>BIT 4、ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_bin 转空 5、自增 auto_increment ==>IDENTITY(1, 1) 6、LONGBLOB==>BLOB 7、两个及以上add字段语法需要分开写，例如： ALTER TABLE ACT_CO_CONTENT_ITEM ADD SCOPE_ID_ VARCHAR(255) NULL, ADD SCOPE_TYPE_ VARCHAR(255) NULL; 修改后： ALTER TABLE ACT_CO_CONTENT_ITEM ADD SCOPE_ID_ VARCHAR(255) NULL; ALTER TABLE ACT_CO_CONTENT_ITEM ADD SCOPE_TYPE_ VARCHAR(255) NULL; 8、修改字段名语法，CHANGE改为rename 例如： ALTER TABLE ACT_CMMN_RU_PLAN_ITEM_INST CHANGE START_TIME_ CREATE_TIME_ datetime(3); 修改后： ALTER TABLE ACT_CMMN_RU_PLAN_ITEM_INST alter column

互联网业务往往使用MySQL数据库作为后台存储，存储引擎使用InnoDB。 我们针对互联网自身业务特点及MySQL数据库特性，讲述在具体业务场景中如何设计表和分表。 本文从介绍MySQL相关基础架构设计入手，并结合企业实际案例介绍分表和索引的设计实战技巧。 一、什么是InnoDB记录存储方式？ 大家都知道在InnoDB存储引擎中记录是按主键顺序存储，并且依靠这个特性为表创建了主键聚簇索引。 InnoDB是如何实现记录“顺序存储”的呢？首先要知道“顺序”分页内顺序和页间顺序，页为InnoDB内外存交换的基本单位。 页间顺序：磁盘文件中页与页之间使用双向链表连接，页间有可能是物理有序。大多数情况是逻辑上的有序； 页内顺序：页内各记录使用单项链表把记录连接起来，所以页内是逻辑有序，配合slot数据结构实现页内接近二分查找的查询效率。 图为InnoDB页内空间分布： Page Header 根据以上特点，我们来分析下使用不同的主键对存储会造成哪些影响： 自增主键： 主键值递增，数据是顺序插入的，所以在页内数据物理连续，写满一页后在顺序分配下一页。在没有删除操作的情况下，整个表的记录在磁盘文件中都是按照写入顺序连续存储的。这中存储方式磁盘利用率非常高，且随机IO很低。插入效率相当高。 业务主键： 比如用户表使用uid做主键，商品表使用infoId做主键，这种有意义的主键，我们称为业务主键

数据库锁知识 不少人在开发的时候，应该很少会注意到这些锁的问题，也很少会给程序加锁(除了库存这些对数量准确性要求极高的情况下)，即使我们不会这些锁知识，我们的程序在一般情况下还是可以跑得好好的。因为这些锁数据库隐式帮我们加了，只会在某些特定的场景下才需要手动加锁。 对于UPDATE、DELETE、INSERT语句，InnoDB会自动给涉及数据集加排他锁（X) MyISAM在执行查询语句SELECT前，会自动给涉及的所有表加读锁，在执行增、删、改操作前，会自动给涉及的表加写锁，这个过程并不需要用户干预 表锁 首先，从锁的粒度，我们可以分成两大类： 表锁 :开销小，加锁快；不会出现死锁；锁定力度大，发生锁冲突概率高，并发度最低 行锁:开销大，加锁慢；会出现死锁；锁定粒度小，发生锁冲突的概率低，并发度高 不同的存储引擎支持的锁粒度是不一样的==：InnoDB行锁和表锁都支持、MyISAM只支持表锁！InnoDB只有通过索引条件检索数据才使用行级锁==，否则，InnoDB使用表锁也就是说，InnoDB的行锁是基于索引的！ 表锁下又分为两种模式： 表读锁（Table Read Lock）&& 表写锁（Table Write Lock） 从下图可以清晰看到，在表读锁和表写锁的环境下：读读不阻塞，读写阻塞，写写阻塞！读读不阻塞：当前用户在读数据，其他的用户也在读数据，不会加锁 读写阻塞

最近在研究如何给MySQL数据库的大表在线添加索引，查询了下资料，MySQL提供了online ddl功能，可以不锁表的执行DDL操作，网络上有些文章有讲解，但是都没有做基准测试。今天正好有空，就做个测试看看online DDL的实际效果。 online DDL简介 online DDL功能为表结构的更改和并发DML提供支持。此功能的优点包括： 几乎不影响线上DML语句的效率。 使用LOCK子句在DDL操作期间调整性能和并发之间的平衡。 与表复制方法相比，磁盘空间使用量和I / O开销更少。 参数介绍[引用1]： ALGORITHM： DEFAULT：默认方式，在 MySQL 8.0中，如果未显示指定 ALGORITHM，那么会优先选择 INSTANT 算法，如果不行再使用 INPLACE 算法，如果不支持 INPLACE 算法则使用 COPY 的方式完成。（8.0以上版本） INSTANT：添加列时立即返回。但是不能是虚拟列。这个原理很简单，对于新建一列，表所有原有数据并不是立刻发生变化，只是在表字典里面记录下这个列和默认值，对于默认的 Dynamic 行格式（其实就是 Compressed 的变种），如果更新了这一列则原有数据标记为删除在末尾追加更新后的记录。这样做就是没有提前预留出列空间，之后更新可能经常会发生行记录空间变动。但是对于大多数业务，都是最近的时间的记录才会修改

这里配置得是单nginx主机。。先准备4台主机，三台mariadb集群，一台nginx。 ------------------------------------------------------------------------------------------------------------------------- mariadb集群配置 环境信息 MariaDB Server：MariaDB-10.2.10 CentOS：CentOS Linux release7.2.1511 (Core) MariaDB Galera Cluster 三个集群节点主机名和IP地址信息： 192.168.1.51 db1 192.168.1.52 db2 192.168.1.53 db3 环境准备，最小化安装CentOS7.2后，安装net-tools-2.0-0.17.20131004git.el7.x86_64.rpm和lrzsz-0.12.20-36.el7.x86_64.rpm，方便远程管理和传输文件。 1. 编辑配置hosts文件 # vi /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.1.51 db1 192.168.1.52 db2 192.168.1.53 db3 2. # vi /etc

mysql中，会涉及到各种表空间的概念，虽然，很多方面这些概念和Oracle有相似性，但也有很多不同的地方，初学者很容易被这些概念弄的晕头转向，从而，混淆这些概念的区别和理解，下面，就简要介绍和说明一下这些表空间的概念。 1.系统表空间（System Tablespace） innodb系统表空间包含innodb数据字典（innodb相关对象的元数据），同时，双写缓冲（doublewrite buffer）、改变缓冲（change buffer）和undo日志（undo logs）等也存储于系统表空间中。此外，系统表空间 也包含用户在改表空间创建的表和索引等数据。由于系统表空间可以存储多张表，因此，其为一个共享表空间。系统表空间由一个或多个数据文件组成，默认情况下，其包含一个叫ibdata1的系统数据文件，位于mysql 数据目录下。系统表空间数据文件的大小和数目由innodb_data_file_path启动选项控制。 2.表文件表空间（File-Per-Table Tablespaces） 表文件表空间是一个单表表空间，该表创建于自己的数据文件中，而非创建于系统表空间中。当innodb_file_per_table选项开启时，表将被创建于表文件表空间中。否则，innodb将被创建于系统表空间中。 每个表文件表空间由一个.ibd数据文件代表，该文件默认被创建于数据库目录中

VARCHAR类型存储空间问题 当MySQL表使用ROW_FORMAT= FIXED时，对于定义VARCHAR类型的列会使用定长存储。 对于VARCHAR类型，除包括字符数据需要的空间外，还额外需要1或2个字节来记录字符串的长度，对于字符串长度小于或等于255字节时使用1个字节表示，大于255字节的字符串的使用2字节表示。对于多字节的字符编码来说，不同字符的编码长度不一样，如对于UTF来说，‘a’需要一个字节来存放，而对于中文‘你’则需要3字节来存放， 因此对于使用UTF8来存放的CHAR(N) 来说，最低使用N字节点空间，最高使用3N字节的空间，因此存储引擎在内部将CHAR类型视为变长字符类型来处理。 使用length(str)来查看str占用的字节数 使用char_length(str)表示str占用的字符数 在MySQL 4 .1版本前，CHAR(N)和VARCHAR(N)中的N指的是字节长度。 从MYSQL 4 .1版本后，CHAR(N)和VARCHAR(N)中的N指的是字符的长度。 对于VARCHAR(N)字段的结尾空格处理： 在MySQL 4 .1及其之前版本，MySQL会截取字符串尾部的空格， 在MySQL 5 .0及之后版本中，MySQL会保留字符串结尾的空格。 如在MySQL 5 .6版本中，使用默认字符集utf8的varchar( 5 )类

点击上方“ 民工哥技术之路 ”，关注并设置“星标” 每天为你带来不一样的干货分享 作者：唐立勇 https://segmentfault.com/a/1190000013672421 一、什么影响了数据库查询速度 1.1 影响数据库查询速度的四个因素 1.2 风险分析 QPS： Queries Per Second 意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS： 是 TransactionsPerSecond 的缩写，也就是事务数/秒。它是软件测试结果的测量单位。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 Tips： 最好不要在主库上数据库备份，大型活动前取消这样的计划。 效率低下的 sql ：超高的 QPS 与 TPS 。 大量的并发：数据连接数被占满（ max_connection 默认 100 ，一般把连接数设置得大一些）。 并发量:同一时刻数据库服务器处理的请求数量 超高的 CPU 使用率： CPU 资源耗尽出现宕机。 磁盘 IO ：磁盘 IO 性能突然下降、大量消耗磁盘性能的计划任务。解决：更快磁盘设备、调整计划任务、做好磁盘维护。 1.3 网卡流量：如何避免无法连接数据库的情况 减少从服务器的数量（从服务器会从主服务器复制日志）

一、什么影响了数据库查询速度 1.1 影响数据库查询速度的四个因素 1.2 风险分析 QPS： Queries Per Second 意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS： 是 TransactionsPerSecond 的缩写，也就是事务数/秒。它是软件测试结果的测量单位。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 Tips： 最好不要在主库上数据库备份，大型活动前取消这样的计划。 效率低下的 sql ：超高的 QPS 与 TPS 。 大量的并发：数据连接数被占满（ max_connection 默认 100 ，一般把连接数设置得大一些）。 并发量:同一时刻数据库服务器处理的请求数量 超高的 CPU 使用率： CPU 资源耗尽出现宕机。 磁盘 IO ：磁盘 IO 性能突然下降、大量消耗磁盘性能的计划任务。解决：更快磁盘设备、调整计划任务、做好磁盘维护。 1.3 网卡流量：如何避免无法连接数据库的情况 减少从服务器的数量（从服务器会从主服务器复制日志） 进行分级缓存（避免前端大量缓存失效） 避免使用 select * 进行查询 分离业务网络和服务器网络 1.4 大表带来的问题（ 重要 ） 1.4.1 大表的特点 记录行数巨大，单表超千万