Mysql

有一个问题是这样的统计数据总数用count(*)、count(主键ID)、count(字段)、count(1)那个效率高。 先说论断，不必那么花里胡哨遇到统计总数全副应用count(*). 然而有很多小伙伴就会问为什么呢？本期文章就解决大家的为什么。 系列文章五分钟，让你明确MySQL是怎么抉择索引《死磕MySQL系列 六》 字符串能够这样加索引，你知吗？《死磕MySQL系列 七》 无奈复现的“慢”SQL《死磕MySQL系列 八》 什么？还在用delete删除数据《死磕MySQL系列 九》 一、不同存储引擎的做法你须要晓得的是在不同的存储引擎下，MySQL对于应用count(*)返回后果的流程是不一样的。 在Myisam中，每张表的总行数都会存储在磁盘上，因而执行count(*)时，是间接从磁盘拿到这个值返回，效率是十分高的。但你也要晓得如果加了条件的统计总数返回也不会那么快的。 在Innodb引擎中，执行count(*)，须要把数据一行一行的读出来，而后再统计总数返回。 问题：为什么Innodb不跟Myisam一样把表总数存起来呢？ 这个问题就须要追溯的咱们之前的MVCC文章，就是因为要实现多版本并发管制，才会导致Innodb不能间接存储表总数。 因为每个事务获取到的一致性视图都是不一样的，所以返回的数据总数也是不统一的。 如果你无奈了解，再回到MVCC文章好好看看，意思就跟不同事务看到的数据不统一一回事。 实战案例 假如这三个用户是并行的，你会看到三个用户看到最终的数据总数都不统一。 每个用户会依据read view存储的数据来判断那些数据是本人能够看见的，那些是看不见的。 read view 当执行SQL语句查问时会产生一致性视图，也就是read-view，它是由查问的那一时间所有未提交事务ID组成的数组，和曾经创立的最大事务ID组成的。 在这个数组中最小的事务ID被称之为min_id，最大事务ID被称之为max_id，查问的数据后果要依据read-view做比照从而失去快照后果。 于是就产生了以下的比照规定，这个规定就是应用以后的记录的trx_id跟read-view进行比照，比照规定如下。 如果落在trx_id<min_id，示意此版本是曾经提交的事务生成的，因为事务曾经提交所以数据是可见的 如果落在trx_id>max_id，示意此版本是由未来启动的事务生成的，是必定不可见的 若在min_id<=trx_id<=max_id时 如果row的trx_id在数组中，示意此版本是由还没提交的事务生成的，不可见，然而以后本人的事务是可见的如果row的trx_id不在数组中，表明是提交的事务生成了该版本，可见二、MySQL对count(*)做了什么优化先来看两个索引构造，一个是主键索引、另一个是一般索引。 当初你应该晓得了，主键索引的叶子节点存储的是整行数据，而一般索引叶子节点存储的是主键值。 得出结论就是一般索引的比主键索引会小很多。 所以，MySQL对于count(*)这样的操作，不论遍历那个索引树失去的后果在逻辑上都一样。 因而，优化器会找到最小的那棵树来遍历，在保障正确的逻辑前提下，尽量减少扫描数据量，是数据库系统设计的通用法令之一。 问题：为什么存储的有数据怎么不必？ 这个图的数据怎么失去的，我想你应该晓得了，没错，就是执行show table status \G;得来的。 那为什么innodb存储引擎不间接应用Rows这个值呢？ 还记不记得在第六期文章中，五分钟，让你明确MySQL是怎么抉择索引《死磕MySQL系列 六》 先不要返回去看这篇文章，看下上文图中最初查到的数据总条数是多少。 你会发现这两个统计的数据是不统一的，因而这个值必定是不能够用的。 具体起因 因为Rows这个值跟索引基数Cardinality一样，都是通过采样统计的。 采样规定 首先，会选出N个数据页，而后统计每个数据页上不同的值，最初失去一个平均值。再用这个平均值乘索引的数据页总数失去的就是索引基数。 并且这个索引基数也不是变化无穷的，会随着数据继续增删改，当变更的数据超过1/M时才会触发，M值是依据MySQL参数innodb_stats_persistent失去的，设置为on是10，off是16。 在MySQL8.0这个默认值为on，也就是说当这张表的数据变更超过总数据的1/10就会从新触发采样统计。 三、不同count的用法以下所有的论断都基于MySQL的Innodb存储引擎。 count(主键ID) innodb引擎会遍历整张表，把每一行的ID值都那进去，而后返回给server层，server层拿到ID后，判断不可能为空，进行累加。 count(1) 同样遍历整张表，但不取值，server层对返回的每一行，放一个数字1进去，判断是不可能为空的，按行累加。 count(字段) 分为两种状况，字段定义为not null和null 为not null时：逐行从记录外面读出这个字段，判断不能为null，累加为 null时：执行时，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。count(*) 这个哥们就厉害了，不是带了就把所有值取出来，而是MySQL做了专门的优化，count （ ）必定不是null，按行累加。 ...

群里一个小伙伴在问为什么MySQL字符串不加单引号会导致索引生效，这个问题预计很多人都晓得答案。没错，是因为MySQL外部进行了隐式转换。 本期文章就聊聊什么是隐式转换，为什么会产生隐式转换。 系列文章字符串能够这样加索引，你知吗？《死磕MySQL系列 七》 无奈复现的“慢”SQL《死磕MySQL系列 八》 什么？还在用delete删除数据《死磕MySQL系列 九》 MySQL统计总数就用count(*)，别花里胡哨的《死磕MySQL系列 十》 文章总目录 一、几大索引生效起因你必定在网上看到过十分多对于索引生效起因的文章，然而肯定要本人亲手尝试一下，因为版本不同引发的后果不会统一。 1.带头大哥不能死 这局经典语句是说创立索引要合乎最左侧准则。 例如表构造为u_id，u_name，u_age，u_sex，u_phone，u_time 创立索引为idx_user_name_age_sex 。 查问条件必须带上u_name这一列。 2.不在索引列上做任何操作 不在索引列上做任何计算、函数、主动或者手动的类型转换，否则会进行全表扫描。简而言之不要在索引列上做任何操作。 3.俩边类型不等 例如建设了索引idx_user_name，name字段类型为varchar 在查问时应用where name = kaka，这样的查问形式会间接造成索引生效。 正确的用法为where name = "kaka"。 4.不适当的like查问会导致索引生效 创立索引为idx_user_name 执行语句为select * from user where name like "kaka%";能够命中索引。 执行语句为select name from user where name like "%kaka";能够应用到索引（仅在8.0以上版本）。 执行语句为select * from user where name like ''%kaka";会间接导致索引生效 5.范畴条件之后的索引会生效 创立索引为idx_user_name_age_sex 执行语句select * from user where name = 'kaka' and age > 11 and sex = 1; ...

在日常开发工作中，你肯定会常常遇到要依据指定字段进行排序的需要。 这时，你的SQL语句相似这样。 select id,phone,code from evt_sms where phone like '13020%' order by id desc limit 10这个SQL的逻辑是非常清晰明了，但其外部的执行原理你知多少。 接下来，本期文章将带你关上order by的大门一探到底。 本期所有论断都基于MySQL8.0.26版本 最新文章字符串能够这样加索引，你知吗？《死磕MySQL系列 七》 无奈复现的“慢”SQL《死磕MySQL系列 八》 什么？还在用delete删除数据《死磕MySQL系列 九》 MySQL统计总数就用count(*)，别花里胡哨的《死磕MySQL系列 十》 文章总目录 一、常见的Extra几个信息在MySQL中想看一条SQL的性能不仅仅看是否用上了索引，还要看Extra中的内容，以下内容来自官网文档，给你最精确的学习材料。 using index 依据索引树可间接检索列信息，无需额定的操作来读取理论的行。 索引列即为查问列，也为条件列。 using index condition 上面这条语句name为一般索引，age无索引。 select * from table where name = ? and age = ? 索引下推是在MySQL5.6及当前的版本呈现的。 之前的查问过程是，先依据name在存储引擎中获取数据，而后在依据age在server层进行过滤。 在有了索引下推之后，查问过程是依据name、age在存储引擎获取数据，返回对应的数据，不再到server层进行过滤。 当你应用Explain剖析SQL语句时，如果呈现了using index condition那就是应用了索引下推，索引下推是在组合索引的状况呈现几率最大的。 using index for group_by 只查索引列，对索引列应用了group by explain select phone from evt_sms where phone = "13054125874" group by phone;using where ...

系列文章五、如何抉择一般索引和惟一索引《死磕MySQL系列 五》 六、五分钟，让你明确MySQL是怎么抉择索引《死磕MySQL系列 六》 七、字符串能够这样加索引，你知吗？《死磕MySQL系列 七》 八、无奈复现的“慢”SQL《死磕MySQL系列 八》 参加了好几个我的项目开发，每个我的项目随着业务量的增大，MySQL数据日益剧增，例如其中一个我的项目中得用户脚印表，那是十分的疯狂，只怪我粗心了，没有闪。 这篇文章我会从delete对性能的影响，以及如何以正确的姿态来删除数据。 在MySQL中Innodb存储引擎的表存在两局部，一部分是表构造，另一部分是表数据。 在MySQL8.0之前/var/lib/mysql下都会存在.frm文件，在MySQL8.0之后就不存在了。这是因为MySQL8.0中曾经容许把表构造定义放到数据字典中了，是用参数innodb_file_per_table来决定的。 一、表空间表空间分为几种，零碎表空间、用户表空间、undo空间。 零碎表空间：MySQL外部的数据字典，如information_schema库下的数据。 用户表空间：本人建设的表构造数据 undo空间：存储Undo信息，用于疾速回滚。 MySQL8.0之前表构造是在零碎表空间存储的，在MySQL5.6.6后能够应用参数innodb_file_per_table来管制。 设置为off时，表数据是放在零碎表空间中，也就是MySQL的数据字典放在一起。 设置为on时，innodb存储引擎的表数据存储在.idb文件中。 你晓得表定义存储在哪里吗？ 来到死磕MySQL系列的专用数据库kaka，新建一张表evt_sms。 猜一下创立的evt_sms表构造定义存储在哪里呢？ 在information_schema库里边的TABLES中，执行查问SELECT TABLE_NAME,TABLE_COMMENT FROM TABLES WHERE TABLE_TYPE='BASE TABLE'; 咱们自定义的表类型是TABLE_TYPE。 说了这么是为了解释如果把innodb_file_per_table设置为off，则表数据也会寄存在这里。 问题：如果数据存在放共享表空间中，表删除了，空间会删除吗？ 答案是不会的。 参数innodb_file_per_table设置为on数据存储在哪里呢？ 个别状况下是在var/lib/mysql中，会看到你创立的数据库，进入到数据库中就能看到一张表对应一个ibd文件。 数据就是存储在这里。 论断 在我的项目开始阶段，切记将innodb_file_per_table设置为on，这是正确的做法。 二、数据删除流程当初你应该晓得Innodb存储引擎用的是B+树数据结构，如下图。 如果当初删了主键ID为4的这条记录，Innodb引擎会把ID为4的这条记录标记为删除，如果之后再插入ID为4的记录，可能会复用这个地位，但磁盘文件大小并不会放大。 隐式字段 这里就牵扯到了mvcc中的一个知识点，MVCC实现原理是由俩个隐式字段、undo日志、Read view来实现的。 上文说的标记删除就是隐式字段中的delete flag，即记录被更新或删除，这里的删除并不代表真的删除，而是将这条记录的delete flag改为true。 在MVCC：据说有人好奇我的底层实现这篇文章中也给大家留下了一个伏笔，数据库的删除是真的删除吗？ 问题：删了一个数据页的所有数据会怎么样 跟单条数据是一样的，整个数据页都是能够复用的。 记录的复用是仅限于合乎范畴条件的数据，例如上文删除的ID为4这条记录，如果在插入ID为4就会复用。 这里须要给大家再聊一个新的知识点页合并，若相邻的两个数据页利用率都很低，零碎就会把这两个数据页合并到一个页上，另一个数据页就会标记为可复用。 问题：应用delete把整个表的数据都删除了会怎么样 答案是，所有的数据页都会标记为可复用，然而磁盘文件大小是不会扭转的。 三、实际全表删除表文件大小不扭转 通过增加数据后表数据曾经达到近100W了，文件大小曾经达到108M。 扩大 这里大家应该能看见stopped，就是执行命令ctrl + z来的，作用是开始咱们在MySQL窗口里边，但不想退出MySQL窗口查看MySQL表文件大小，而后就能够执行这个命令结束任务。 查看完后能够在执行fg返回到MySQL窗口。 问题：Linux如何把文件单位显示为M 假如刚刚间接执行ll命令查看文件，那么就须要手动计算文件大小，很不不便。 执行ll -h命令则能够直观的看到文件大小。 ...

@TOC 系列文章三、MySQL强人“锁”难《死磕MySQL系列 三》 四、S 锁与 X 锁的爱恨情仇《死磕MySQL系列 四》 五、如何抉择一般索引和惟一索引《死磕MySQL系列 五》 六、五分钟，让你明确MySQL是怎么抉择索引《死磕MySQL系列 六》 置信大多数小伙伴跟咔咔一样，给字符串增加索引从未设置过长度，明天就来聊聊如何正确的给字符串加索引。 一、如何建设索引大多数零碎都会存在用户表，并且零碎初始设计应用了手机号码登录的。 这是产品提出了一个需要，让零碎也能够反对邮箱登录。 必定晓得的是若不给邮箱字段增加索引执行查问是会全表扫描。 此时你心里窃喜这还不简略，给邮箱字段加个索引完事呗！但要做到简单的需要做好，简略的需要要最好，加重所有对系统的压力。 此时的你拿起键盘就执行了alter table table_name add index idx_field (field) 有局部小伙伴不喜爱命令行创立索引，喜爱应用phpmyadmin工具来操作MySQL，那么在建设索引时有没有发现后边能够设置大小呢？ 通过上边给大家展现的图片晓得字符串建设索引是能够定义长度的，那么两者有什么区别。 应用命令行alter table table_name add index idx_field (field)间接创立的索引默认是蕴含整个字符串。 若这样执行就指定了索引前缀长度alter table table_name add index idx_field (field(6)) 一图解千愁，看一下建设的两个索引构造是什么样的。 索引一结构图 索引二结构图 从图中能够看到，指定了索引长度为6那么就只取邮箱字段的前6个字段，绝对索引蕴含整个字符串来说每个节点存储的数据会更多。 索引那篇文章也给大家说了建设索引在适合的范畴内越小越好。 万物皆两面，有坏就有好，第六期文章误选索引的因素之一就是扫描行数。 索引长度缩小带来的影响就是索引基数变大，从而减少额定的扫描记录数（执行explain的row字段）。 此时要执行select id,name,email from mac_user where email='1397393964@qq.com'; 给整个字符串增加索引执行流程 1、从email索引树找到满足1397393964@qq.com的记录，失去主键ID为1 2、依据ID为1到主键索引树找到这条记录并判断email是否正确，将这行记录如果后果集。 3、反复第一步，直到不满足查问条件，循环完结。 指定索引长度执行流程 1、从email索引树找到满足139739的记录，失去主键ID为1 2、依据ID为1到主键索引树找到这条记录并判断email不正确，抛弃这行记录。 3、在email索引树找刚刚查问的下一条记录，发现还是139739，去除ID2，再到ID的索引树进行判断，当值对后退出后果集。 4、再持续反复上一步，直到不满足查问条件，循环完结。 论断 在模仿执行流程过程中很容易就发现，应用前缀索引会导致读取数据的次数减少，那是不是就代表应用前缀索引会减少查问代价呢？ ...

系列文章二、毕生挚友redo log、binlog《死磕MySQL系列 二》 三、MySQL强人“锁”难《死磕MySQL系列 三》 四、S 锁与 X 锁的爱恨情仇《死磕MySQL系列 四》 五、如何抉择一般索引和惟一索引《死磕MySQL系列 五》 如果你对索引的知识点还不太分明，能够间接通过传送门查看咔咔总结的索引知识点。 揭开MySQL索引神秘面纱 索引是为减速查问速度，创立的索引也合乎所有规定，但MySQL就是不应用现实的索引，导致查问速度变慢并产生大量慢查问记录。 明天就从这个问题来聊聊MySQL抉择索引时都做一些什么事件。 一、如何抉择索引影响优化器的几大因素一条查问SQL执行须要通过连接器、分析器、优化器、执行器，而抉择索引的重任就交给了优化器。 优化器在多个索引中抉择目标是为了找出执行代价最低的计划。 影响优化器抉择无非就这几个因素，扫描行数、是否应用了长期表、是否应用文件排序。 长期表、文件排序这个两个点会在前期文章给大家缓缓引出，明天只聊扫描行数。 扫描行数越少则拜访磁盘数据的次数就越少，耗费的CPU资源越少。 那么这个扫描行数是从哪里取的呢？ 扫描行数从何而来？创立索引始终提倡大家给区分度高的列建设索引，在一个索引上不同值的个数称之为基数（cardinality）。 应用show index from table_name能够查看每个索引的基数是多少。 索引基数怎么计算 MySQL应用采样统计的办法，会选出N个数据页，每个数据页大小16kb，接着统计选出来的数据页上的不同值就会失去一个平均值，用平均值在乘以索引的页面数失去的后果就是这个索引的基数。 表数据是继续减少或删减的，统计的这个数据也不是时时变动的，当变更的数据超过1/M时会主动触发从新计算。 这个M是依据参数innodb_stats_persistent的值选则的，设置为on值为10，设置为off值为16。 索引基数通过这种形式计算不是精准的但也差不了多少 为什么优化器抉择了扫描行数多的索引？第一种状况 表增删非常频繁，导致扫描行数不精确 第二种状况 假如你主键索引扫描行数是10W行，而一般索引须要扫描5W行，这种状况就会遇到优化器抉择了扫描行数多的。 在索引那一期文章中晓得主键索引是不须要回表的，找到值间接就返回对应的数据了。 而一般索引是须要先拿到主键值，再依据主键值获取对应的数据，这个过程优化器抉择索引时须要计算的一个老本。 如何解决这种状况 扫描行数不精确时能够执行analyze table table_name命令，从新统计索引信息，达到预期优化器抉择的索引。 二、索引抉择异样如何解决计划一 在MySQL中提供了force index来强制优化器应用这个索引。 应用办法：select * from table_name force index (idx_a) where a = 100； 但别误会force index的应用办法，之前在代码中看到这样一个案例，给查问列应用了函数操作导致应用不上索引，而后这哥们就间接应用force index，必定不行的哈！ 当优化器没有正确抉择索引时是能够应用这种计划来解决。 毛病 应用force index的毛病置信大家也晓得就是太死板，一旦索引名字改变就会生效。 计划二 删掉误选的索引，简略粗犷，很多索引建设其实也是给优化器的一个误导，间接删掉即可。 计划三 批改SQL语句，被动疏导MySQL应用冀望的索引，个别状况这种做法应用的很少除非你对系统非常相熟，否则尽量少操作。 ...

系列文章一、原来一条select语句在MySQL是这样执行的《死磕MySQL系列 一》 二、毕生挚友redo log、binlog《死磕MySQL系列 二》 三、MySQL强人“锁”难《死磕MySQL系列 三》 下边两幅图还相熟吧！就是第三期文章中的前言，但上一期文章并未提及死锁，只是引出了全局锁、表锁的概念。本期文章将持续聊聊锁的内容。 Lock wait timeout exceeded; try restarting transaction Deadlock found when trying to get lock; try restarting transaction 一、行锁行锁的锁粒度最小，发送锁抵触的概率最低，并发度也最高。 问题：MySQL的所有存储引擎都反对行锁吗？ 不是的，MySQL中只有Innodb存储引擎才反对行锁，其它的并不反对，MyIsam存储引擎也只反对表锁。 所以Myisam存储引擎只能应用表锁来解决并发，表锁开销小，加锁快，锁定粒度大，产生锁抵触的概率最高，并发度最低。 问题：锁粒度指的是什么？ 这种名词不能只记名字，须要晓得其代表的含意。锁粒度指的是加锁的范畴。 上期文章讲的全局锁锁的是整库、表锁锁定的全表、行锁指的是锁定某一行或某个范畴的数据。 问题：如何加行锁？ Innodb存储引擎在执行update、delete、insert语句时会隐式加排它锁，而对于select不会加任何锁。 同样也能够手动加锁。 共享锁：select * from tableName where id = 100 lock in share more 排它锁：select * from tableName where id = 100 for update 共享锁、排它锁也被称之为读锁、写锁。读锁与读锁之间不互斥，读锁与写锁、写锁与写锁之间是互斥的。 问题：为什么要加锁？ MySQL事务的四大个性别离是原子性、隔离性、一致性、持久性，当你理解完事务的四大个性之后就发现都是为了保证数据一致性为最终目标的。 常说一句话有人中央就有江湖，放在MySQL中是有锁的中央就有事务。 所以说加锁就是为了保障当事务完结后，数据库的完整性束缚不被毁坏，从而确保数据一致性。 二、两阶段锁问题：两阶段锁是什么？ 说实话，这个名字属实很唬人，猛然间你有没有想到另一个名词两阶段提交。这里回顾一下，两阶段提交是确保redo log跟binlog同时提交胜利，若有一方提交失败则回滚。 在Innodb存储引擎中，行锁是在须要的时候加上的，但并不是不须要了就间接开释的，而是要等到事务完结才开释。 ...

系列文章一、原来一条select语句在MySQL是这样执行的《死磕MySQL系列 一》二、毕生挚友redo log、binlog《死磕MySQL系列 二》 最近数据库老是呈现上面死锁状况，借着这俩种状况登程具体的了解一下MySQL中的锁。 Lock wait timeout exceeded; try restarting transaction Deadlock found when trying to get lock; try restarting transaction 一、MySQL中有那些锁全局锁 依据全局两个字，就能够必定的是给一个整体加上锁。全局锁就是对整个数据库实例加锁。 对于flush tables with read lock，执行实现后整库就处于只读状态，所有语句将被梗塞，包含增删改查、创立表、批改表构造等语句。 表锁 表锁大家都十分相熟了，执行命令lock tables kaka read ,kaka2 write直到unlock tables之前，其它线程是无奈对kaka写kaka2读的。 执行命令的这个线程也只能够对kaka读，kaka2写。 行锁 行锁是在引擎层由各个引擎本人实现的。在MySQL中Innodb存储引擎反对行锁，若不反对行锁意味着并发管制只能应用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度。（因为篇幅的起因，下期细谈） 二、全局锁演示执行flush tables with read lock命令后数据库处于什么状态。 终端1执行全局锁命令 端口2执行删除操作，它不会间接执行胜利，而是在端口1解锁后返回。 这个SQL须要3分钟的执行工夫，这3分钟就是咔咔关上终端2并连贯数据库的工夫。 当初见证了开篇所说的全局锁间接让整个库处于只读状态，这里只演示了删除操作其它的几个操作本人尝试一下。 在蒋老师的文章中看到全局锁最典型的场景是用于逻辑备份，即是将整个库的每一个表都select存储成文本。 当初，你想想这种场景是在什么须要下呈现的。 如果只有一个主库，执行了全局锁整库处于只读状态，那么业务根本停摆，产品无奈应用。 此时你会有疑难我在从库上备份啊！备份期间，不能执行主库同步过去的binlog的，数据量如果十分大，将引发主从提早过大，必须进行全量备份。 以上是全局锁引发的负面状况，但再看备份不加全局锁会呈现什么问题。 置信大多数小伙伴都开发过领取类我的项目，接下来就用领取案例让大家很清晰的了解备份不加全局锁引发的问题。 发动一个逻辑备份。如果一个用户在备份期间购买了你公司的服务，在业务逻辑先扣除用户余额，而后给用户增加你公司对应的产品。 显然，这个逻辑没有问题的，但在非凡案例下执行备份操作就会引发问题。 若在工夫程序上先备份用户余额，而后用户发动购买，接着备份用户购买的产品表。 一个十分清晰的问题呈现了，用户余额没减胜利但用户却取得了对应的产品。 从用户的角度登程那是赚大发了，但这种执行程序如果反过来的话就会产生不一样的后果。 先备份用户产品表，而后备份用户余额表，就会呈现用户钱花了货色没得着，这还得了，用户都是衣食父母这不是再割父母的韭菜。 也就是说，在备份不加锁的话，不同表之间的执行备份的程序不同，如果某个表在备份的过程中进行了更新并且胜利备份而关联的表曾经备份实现无奈再进行跟新，此时就会呈现数据不统一。 在MVCC那篇文章中提到了一个十分重要的概念一致性视图（read view），一致性视图是依据快照读那一刻所有未提交事务的汇合，前提是隔离级别为可反复。 ...

系列文章原来一条select语句在MySQL是这样执行的《死磕MySQL系列 一》毕生挚友redo log、binlog《死磕MySQL系列 二》 上期依据一条查问语句查问流程剖析MySQL的整体架构。同样，本期也应用一条查问SQL语句来做引子。能够必定的是，查问语句执行的流程更新语句同样也会执行。 因而本期的着重点就不在MySQL架构图上，文章题目也给出了大家重点，就是要理解redo log、binlog。 一、redo log第一步，创立一个表 user，主键是 id，上面是创立语句。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `age` tinyint(4) NOT NULL, `time` int(11) NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4插入一条数据 insert into user (`name`,`age`,`time`) values ("咔咔","25",unix_timestamp(now()))若要将插入的这条数据的age改为26，则须要执行语句 update user set age = 26 where id = 1;第一期文章中提到一条查问语句的执行流程，该流程与更新语句雷同。这里将那幅图拿过去在相熟一下。 每个模块的性能能够回到第一期文章去查看。 在MySQL8.0中redo log、binlog日志文件都位于/var/lib/mysql此目录下，如图 文件名为ib_logfile的是重做日志，undo结尾的就是回滚日志，对于回滚日志前期进行具体的探讨。 redo log（重做日志）是实现事务持久性必备因素，当一个事务提交后，并非间接批改数据库的数据，而是首先保障在 redo log中记录相干的操作。 Innodb存储引擎中的redo log大小是固的，上图显示配置了一组两个文件，每个文件大小默认为48M，应用innodb_log_file_size参数来管制单个文件大小，在MySQL5.6.8以及之后版本都默认为48M。 而后redo log能够记录48M的操作，redo log是一个闭环的循环写。所设定的文件个数和文件大小不再减少。 ...

看到蒋老师的第一篇文章后就收货颇丰，真是句句戳中痛点。 令我记忆最深的就是为什么晓得了一个个技术点，却还是用不好 ？不论是蒋老师所说的Redis还是本系列要开展学习的MySQL。 这是一个值得思考的问题，在大多数状况下，咱们间接上百度搜寻MySQL事务、MySQL索引之类的词汇。 上述问题当然也是MySQL的几个外围问题之一，但如果咱们都在一直地学习这些大的方面，咱们怎么能力在学习某一个技能上有质的晋升。 借用蒋老师的话术：“很多技术人都有一个误区，就是只重视零散的技术，没有建设一个残缺的常识架构，不足零碎观，然而，零碎观却是至关重要的。在解决问题的时候，从某种意义上来说，领有零碎观，就意味着你有根据、有章法去定位并解决问题。” 如果你对这些话也深有体会，那就跟咔咔一起建设一套MySQL的常识框架，对于这种思维也是第一次实战，心愿大家多多提意见。 一、从宏观的角度剖析MySQL首先看一张经典图片 这幅图预计很多人都看到过，也是经典之作高性能MySQL里边的，如果有趣味能够先看一下电子版的（如须要电子版可分割咔咔），感觉本人能看进去了，再去买书也来的急。 闲话少说，进入正题。 上图的客户端能够间接了解为PHP、Java等。接下来，你会看到连贯、线程解决。这一部分并不是MySQL所特有的，而且大多数客户端、服务器都具备相似的构造。 因而，一般而言，MySQL能够分为两层：Server层和存储引擎层。 Server层次要包含连贯层、查问缓存、分析器、优化器、执行器等重要模块组成，这一层还蕴含了MySQL外围Api局部，比方罕用的格式化工夫、加密等。 存储引擎大家都很相熟，因为在面试中不止一次的问过大家Innodb、Myisam存储引擎的不同。 所以想过没有，MySQL为什么会有这么多的存储引擎呢？ 所有技术起源于当下问题，同样在MySQL中也不例外。 MySQL在存储引擎这一方面的架构是插件式的，即能够随便切换不固定，而且MySQL5.5版本存储引擎曾经默认为Innodb。 二、一条SQL执行要通过多少艰难？下图是咔咔之前培训时给发的材料 图中还有一个相熟的陌生人查问缓存模块，该模块在MySQL8.0中已不存在。 对于该模块为何要被删除，后续的文章也将于大家交换。 首先，咱们将大抵理解当咱们执行一条SQL语句时，如何在这个架构图中运行。 2-1 连接器mysql -u root -p连贯数据库命令，在执行之后，你将须要输出明码。当实现经典的TCP握手之后，连接器就开始发挥作用了。 如果码谬误时，则返回Access denied for user ‘root‘@‘localhost‘ (using password: YES，谬误编码1045。 如果连贯信息均正确，则此时将依据你输出的用户拜访权限表来获取该用户的权限，此处必须分明，当你登录胜利后，即便其他人批改了你的权限，在这个连贯未断开之前你的权限是不会产生扭转的。 当你连贯实现之后，如果你始终不做任何事件，执行show processlist将会看到一个sleep，示意空连贯。 那么你晓得在MySQL中，如果连贯胜利后没有进行任何操作，多久会被主动中断？ 能够执行show variables like 'wait_timeout';用于查看工夫。 在MySQL中如果没有特地阐明，那么所有的工夫都是以秒为单位的，依据工夫转换能够得悉空连贯继续8小时。 2-2 查问缓存你须要留神的是，MySQL8.0曾经被勾销了，这个问题不止说了一次了，特地是那些正在应用MySQL8.0以下版本的小伙伴要留神哈！当你切换到8.0时候，遇到这个问题不晓得怎么解决。 MySQL8.0为何勾销查问缓存模块 这个模块的设计，把查问语句作为key ，将后果作为value 进行缓存，一旦这个表有更新，之前所有的缓存都会被革除掉。这就像你辛辛苦苦写的代码提交之后被他人笼罩一样好受。 MySQL8.0以下的版本提供了一个参数query_cache_type = enmand来管制是否要应用查问缓存，在设置实现后，默认的select语句将不会被缓存。 如果的确能够应用局部场景，那么你能够将sql_cache增加到select关键字之后。 如果一条select语句之前被缓存过，那么后果集在这里就会间接返回，而没有缓存过的select语句就比拟辛苦了，还要持续本人的漫漫长路。 2-3 分析器MySQL8.0之前，它会在进入分析器之前判断是否缓存，在MySQL8.0之后，连接器验证胜利后就间接进入分析器。 分析器，依据字面意思来了解就是剖析要执行的SQL语句是什么，要做什么。 比方执行select * from user where id = 1 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答0. 导读雷同的账号、明码，手动客户端连贯能够胜利，通过MySQL Connectors却失败了，为什么？1. 景象形容通过MySQL C API编写的一个程序，在进行用户登录操作的时候，程序报错，登录失败。 然而如果通过mysql客户端，手动登录胜利后，再启动客户端程序，不再报错，程序运行胜利。 2. 抓包剖析问题学会抓包，就超过了90%的程序员。sudo tcpdump -i any tcp and port xxx -s 1500 -w filename -vC程序登录失败时的包 前两个包很失常，第三个包第一次见，wireshark解析的叫做 AuthSwitchRequest. 看下这个包的内容。 mysql客户端登录胜利后，再执行C程序登录胜利时的包 看下这个AuthSwithRequest包的内容。 认证胜利和失败的包数据是不同的，别离是03和04。 3. AuthSwitchRequest包首先看下AuthSwitchRequest包的官网解释。 Protocol::AuthSwitchRequest:Authentication Method Switch Request Packet. If both server and client support CLIENT_PLUGIN_AUTH capability, server can send this packet to ask client to use another authentication method.Payload1 [fe]string[NUL] plugin namestring[EOF] auth plugin data能够看出，这个包payload的第一个字节是0xfe，与抓包中的01是不同的，而且AuthSwitchRequest前面跟的应该是plugin name，是个字符串，而抓包中，内容是04。 所以wireshard解包谬误了。 在协定外面咱们找下payload第一个字节是01的包，找到了AuthMoreData的包。 ...

@TOC 数据实时增量同步工具之go-mysql-transfer：https://blog.csdn.net/weixin_... Elasticsearch笔记之装置、配置、Kibana根底：https://blog.csdn.net/weixin_... go-mysql-transfer官网手册：https://www.kancloud.cn/wj596... GO笔记之环境装置：https://blog.csdn.net/weixin_... 技术选型：Mysql8 + go-mysql-transfer + ElasticSearch7.13 简介go-mysql-transfer是一款MySQL数据库实时增量同步工具。须要GO环境 可能监听MySQL二进制日志(Binlog)的变动，将变更内容造成指定格局的音讯，实时发送到接收端。从而在数据库和接收端之间造成一个高性能、低提早的增量数据同步更新管道。 工作须要钻研了下阿里开源的MySQL Binlog增量订阅生产组件canal，其功能强大、运行稳固，然而有些方面不是太合乎需要，次要有如下三点： 1、须要本人编写客户端来生产canal解析到的数据 2、server-client模式，须要同时部署server和client两个组件，咱们的我的项目中有6个业务数据库要实时同步到redis，意味着要多部署12个组件，硬件和运维老本都会减少。 3、从server端到client端须要通过一次网络传输和序列化反序列化操作，而后再同步到接收端，感觉没有间接怼到接收端更高效。 前提条件MySQL 服务器须要开启 row 模式的 binlog。因为要应用 mysqldump 命令，因而该过程的所在的服务器须要部署这一工具。这一工具应用 GoLang 开发，须要 Go 1.9+ 的环境进行构建。新版(7.13+)的本地es必须敞开平安模式才能够 yml配置文件增加 xpack.security.enabled: false可用的 MySQL、Elasticsearch 以及 Kibana 实例。权限须要大一些。 mysql binlog必须是ROW模式要同步的mysql数据表必须蕴含主键，否则间接疏忽，这是因为如果数据表没有主键，UPDATE和DELETE操作就会因为在ES中找不到对应的document而无奈进行同步不反对程序运行过程中批改表构造要赋予用于连贯mysql的账户RELOAD权限以及REPLICATION权限, SUPER权限GRANT REPLICATION SLAVE ON *.* TO 'elastic'@'IP';GRANT RELOAD ON *.* TO 'elastic'@'IP';UPDATE mysql.user SET Super_Priv='Y' WHERE user='elastic' AND host='IP'；个性1、简略，不依赖其它组件，一键部署2、集成多种接收端，如：Redis、MongoDB、Elasticsearch、RocketMQ、Kafka、RabbitMQ、HTTP API等，无需编写客户端，开箱即用3、内置丰盛的数据解析、音讯生成规定，反对模板语法4、反对Lua脚本扩大，可解决简单逻辑，如：数据的转换、荡涤、打宽5、集成Prometheus客户端，反对监控、告警6、集成Web Admin监控页面7、反对高可用集群部署8、数据同步失败重试9、反对全量数据初始化 与同类工具比拟特色Canalmysql_streamgo-mysql-transferMaxwell开发语言JavaPythonGolangJava高可用反对反对反对反对接收端编码定制Kafka等(MQ)Redis、MongoDB、Elasticsearch、RabbitMQ、Kafka、RocketMQ、HTTP API 等Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件等全量数据初始化不反对反对反对反对数据格式编码定制Json（固定格局）Json（规定配置) 模板语法 Lua脚本JSON性能(4-8TPS) 实现原理1、go-mysql-transfer将本人伪装成MySQL的Slave， 2、向Master发送dump协定获取binlog，解析binlog并生成音讯 ...

本文首发：MySQL 连接数过多的解决办法合集 - Too many connections - 卡拉云 碰到Can not connect to MySQL server. Too many connections”-mysql谬误着实令人抓狂。这根本等于失去了对 MySQL 的控制权。本教程将具体解说多种解决此谬误的办法。 sudo mysql -uroot -pERROR 1040 (00000): Too many connections本教程将分这几个来解说此类谬误的起因。 如何查看 MySQL 连贯状态？如何查看以后 MySQL 连接池是否已满？限度超时工夫的办法，缩短 sleep 工夫，使零碎更快回收连贯。批改配置文件中最大连接数的办法，保障连贯畅通。前线救济法，不必重启，不必登录 MySQL，即可批改最大连接数。提前布局，给 root 预留好连贯通道。一. 谬误起因呈现 MySQL 连接数过多有多种状况，少数是因为mysql_connect ，没有 mysql_close; 当sleep连贯占满最大连接数max_connections时，会导致 Too many connections 谬误。 MySQL 默认最大连接数max_connections为 151，其实 MySQL 还给 root 留了多一个通道，真正的最大连接数为max_connections + 1 。但理论工作中因为各种起因，这个 1 也有可能被占用。这时，咱们无奈通过登录 MySQL 调整参数的办法来解决这个谬误。 二. 查看以后 MySQL 连贯状况咱们能够应用 SHOW PROCESSLIST; 查看前 100 条连贯。 SHOW PROCESSLIST;也能够应用 SHOW full PROCESSLIST; 查看所有连贯。 ...

场景形容我的项目中需要对数据进行迁徙，数据之间存在外键关联关系，外键关系存在一对多；因而在数据迁徙之后，须要将对应的外键更新；则迁徙须要一次性实现，否则须要额定的工作量来修复外键关系（次要操作为BatchInsert、BatchUpdate） 问题裸露该需要迁徙数据量为亿级，运行一段时间后，发现有3组数据迁徙不胜利，通过日志排查，发现Mybatis报错，超过程序能解决的最大量，通过查问，发现最多一组数据量有12w 问题起因Mysql 对语句的长度有限度，默认是 4M （select @@max_allowed_packet）经查阅我的项目数据库配置的最大包为16M，并不足以反对10w级数据量的解决，故报错 后续跟进因为我的项目业务起因，已通过其余伎俩解决此问题，在当前的工作中，遇到批量解决数据的操作，还须要全面评估以躲避数据量带来的数据传输问题

本文首发：MySQL 配置文件 my.cnf / my.ini 逐行详解 - 卡拉云 MySQL 配置文件的意义充沛了解 MySQL 配置文件中各个变量的意义对咱们有针对性的优化 MySQL 数据库性能有十分大的意义。咱们须要依据不同的数据量级，不同的生产环境状况对 MySQL 配置文件进行优化。 Windows 和 Linux 下的 MySQL 配置文件的名字和寄存地位都是不同的，WIndows 下 MySQL 配置文件是 my.ini 寄存在 MySQL 装置目录的根目录下；Linux 下 MySQL 配置文件是 my.cnf 寄存在 /etc/my.cnf、/etc/mysql/my.cnf。咱们也能够通过 find 命令进行查找。 另外要留神的是，通过 rpm 命令装置的 MySQL 是没有 /etc/my.cnf 文件的，如果须要配置 MySQL，能够在/etc/my.cnf新建配置文件，而后把本文的配置信息复制到文件中即可。 本教程将率领大家逐条解析最新的 MySQL 8.0 的配置文件，争取搞懂每一条变量。当然，咱们了解了变量的意义外，更重要的是针对本人的数据库外部环境，在实践中进行微调，以达到优化性能的目标。 提醒：你能够应用 Ctrl+F 疾速定位。 MySQL 配置文件详解 [client][mysqld_safe][mysqld]Query Cache MySQL 谬误日志设置 慢查问记录 全局查问日志隶属线程变量平安变量MyISAM 变量MEMORY 变量InnoDB 变量 WSREP 配置MySQL 配置文件详解文件地位: Windows、Linux、Mac 有轻微区别，Windows 配置文件是 .ini，Mac/linux 是 .cnf [Windows]MySQL\MySQL Server 5.7\my.ini[Linux / Mac]/etc/my.cnf/etc/mysql/my.cnf 当然咱们也能够应用命令来查看 MySQL 默认配置文件地位 ...

I、事务的启动机会事务在启动时会拍一个快照，这个快照是基于整个库的。即一个事务内,整个库的批改对于该事务都是不可见的(对于快照读的状况)。如果在事务内select t表,另外的事务执行了DDL t表，依据产生工夫，会呈现锁住或者报错。1、一致性视图是在执行第一个快照读语句时创立的：begin/start transaction命令并不是一个事务的终点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。2、一致性视图是在执行 start transaction with consistent snapshot 时创立的：如果你想要马上启动一个事务，能够应用 start transaction with consistent snapshot 这个命令。 II、隔离级别实现Innodb反对RC和RR隔离级别实现是用的一致性视图(consistent read view) III、事务是如何实现的MVCC1、每个事务都有一个事务ID，即严格递增的transaction id；2、事务在启动时，找到已提交的最大事务ID记为up_limit_id；3、事务在更新一条语句时，比方id=1改为了id=2，会把id=1和该行之前的row trx_id写到undo log里，并且在数据页上把id的值改为2，并且把批改这条语句的transaction id记在该行行头；4、再定一个规矩，一个事务要查看一条数据时，必须先用该事务的up_limit_id与该行的transaction id做比对，如果up_limit_id>=transaction id，那么能够看。如果up_limit_id<transaction id，则只能去undo log里去取。去undo log查找数据的时候，也须要做比对，必须up_limit_id>transaction id，才返回数据。 IV、什么是以后读因为以后读都是先读后写，只能读以后的值，所以为以后读。会更新事务内的up_limit_id为该事务的transaction id。 V、为什么rr能实现可反复读而rc不能1、快照读的状况下，rr不能更新事务内的up_limit_id，而rc每次会把up_limit_id更新为快照读之前最新已提交事务的transaction id，则rc不能可反复读；2、以后读的状况下，rr是利用record lock+gap lock来实现的，而rc没有gap，所以rc不能可反复读。 VI、MYSQL两个视图概念1、一个是 view。它是一个用查问语句定义的虚构表，在调用的时候执行查问语句并生成后果。创立视图的语法是 create view … ，而它的查询方法与表一样。2、另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于反对 RC（Read Committed，读提交）和 RR（Repeatable Read，可反复读）隔离级别的实现。

从零开始学Mysql - 字符集和编码（上）前言 上一节咱们零碎的论述了对于系统配置的相干细节内容，而这一节咱们须要理解对于字符集和编码的内容，字符集和编码的规定其实也算是入门mysql常常遇到的一个坑，根本每个人学习过程必定会遇到数据库存储中文然而读出来是：“???”的这种问题，好了废话不多说，咱们来看下mysql的字符集和编码的规定。 编码简略介绍 对于编码和解码，简略来讲编码就是把字符转变为二进制数据，解码就是把二进制的数据依照肯定的规定翻译成字符，对于编解码的定义只须要理解两个重点： 字符是如何映射成为二进制数据的那些字符须要映射二进制的数据 比方咱们把abcd拆分成四种自定义的编码格局，应用十六进制示意，a占一位，b占两位，c占3位，d占四位，咱们能够应用含有abcd的字符进行不同的组合编码，然而不能对于ef，或者zh等等字符进行编码，因为咱们设计的规定不意识这些字符，编码之后的数据依照本人设计的编码解码翻译回原来的数据，这就是最简略的编码和解码规定。 如何比拟大小 咱们晓得了如何对于字符进行编码，那么咱们如何对于字符进行比拟呢？咱们最可能想到的规定是依照26个字母的程序进行比拟排序大小，其实二进制的比拟规定是非常简单的，然而咱们会发现有时候会呈现非凡的状况，比方英文有大小写之分，而中文又有同音字的等等，这时候就不能简略二进制比拟了，咱们须要做如下的调整： 将字符对立转为大写或者小写再进行二进制的比拟或者大小写进行不同大小的编码规定编码 所以其实咱们能够发现一个字符可能会存在多个比拟形式，最终意味着字符集会呈现多种的比拟规定模式。 字符集介绍常见字符集 通过下面的编码介绍之后，上面咱们来介绍对于字符集的内容，全世界的字符集怎么也得又个成千盈百种，这还不蕴含各种借鉴的字符集，然而实际上支流的也就那么几种，比方：GBK2312，UTF-8，UTF-16等等，所以这里只简略列举几个常见的字符集： ASCII 字符集：共收录128个字符，包含空格、标点符号、数字、大小写字母和一些不可见字符，一共也就128个字符，所以能够间接用一个字节示意，比方上面的内容： 'L' -> 01001100(十六进制:0x4C，十进制:76)'M' -> 01001101(十六进制:0x4D，十进制:77)ISO 8859-1 字符集：欧洲的通用编码，一共是256个字符，次要是在ASCII 字符集字符集的根底上扩大了128个字符，这个字符集也被称为：latin1（拉丁1，有点好奇为什么叫这个名）GB2312：这个编码其实误导性挺强的，因为根本都晓得这是给国人用的，可能会认为只有汉字的编码，其实它收录了汉字以及拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母等多个语言。其中收录汉字6763个， 其余文字符号682个，同时这种字符集又兼容 ASCII 字符集，所以编码方式比拟非凡： ASCII 字符集：依照ASCII 字符集的规定应用一个字节其余的GB2312反对的字符集：应用两个字节进行编码（汉字切实是多，这种编码收录的也是笼罩了最为罕用和经常出现的）如果呈现ASCII和其余字符集混用，字符须要的字节数可能不同的编码方式称为 变长编码方式，比方'啊A'的中文字符须要两个字节编码，然而A须要一个字节的编码，最初再把 “两个字符”进行二进制编码的拼凑。 这些数字不是敏感词，不须要记住数量，只有留神gb2312并不只是只有中文。 补充：这里可能有小伙伴好奇GB2312是怎么意识不同的字符集的，其实很简略，ASCII只有128个，所以只有是在这个范畴的，根本能够判定就是ASCII的字符集，所以应用一个字符即可，如果不在这个范畴，间接应用两个字节翻译即可。 GBK 字符集：对于GB2312进行字符集的扩大，其余无变动UTF8 字符集：用苹果的广告词来说就是强人的强的一个字符集，蕴含了地球上的所有字符，而且因为不同字符集编码的字节数不同，所以UTF-8规定依照1-4个字节的变长编码方式进行编码，最初UTF8和gbk一样也兼容了ASCII的字符集。补充：既然提到了UTF-8，那么这里就来说一下Unicode编码的事件，其实精确来说utf8只是Unicode字符集的其中一种编码方案，Unicode字符集能够采纳utf8、utf16、utf32这几种编码方案，utf8应用1~4个字节编码一个字符，utf16应用2个或4个字节编码一个 字符，utf32应用4个字节编码一个字符。 另外，Mysql晚期的utf8并不是真正意义上的utf8这个后续会进行补充 最初咱们能够发现，对于同一个字符在不同的字符集会有不同的编码方式，对于一个汉字来说，ASCII字符集没有收录，上面咱们比拟utf-8和gbk是如何收录的，比方一个字符的'我'汉字假如是如下的编码方式： utf8编码:111001101000100010010001 (3个字节，十六进制示意是:0xE68891)gb2312编码:1100111011010010 (2个字节，十六进制示意是:0xCED2)如何查看字符集 查看字符集的命令非常简略：show (character set|charset) [like 匹配模式]，括号内示意能够任选其中一个，比方抉择character set，当然比拟难打，所以charset更罕用一些，记住这一个即可。 上面是具体的案例，能够看到目前mysql反对41种字符集： > show charset;armscii8 ARMSCII-8 Armenian armscii8_general_ci 1ascii US ASCII ascii_general_ci 1big5 Big5 Traditional Chinese big5_chinese_ci 2binary Binary pseudo charset binary 1cp1250 Windows Central European cp1250_general_ci 1cp1251 Windows Cyrillic cp1251_general_ci 1cp1256 Windows Arabic cp1256_general_ci 1cp1257 Windows Baltic cp1257_general_ci 1cp850 DOS West European cp850_general_ci 1cp852 DOS Central European cp852_general_ci 1cp866 DOS Russian cp866_general_ci 1> show charset like 'big%';big5 Big5 Traditional Chinese big5_chinese_ci 2 上面是须要记忆的几个字符集，也是最罕用的字符集： ...

这个问题其实能够分为有主键 & 无主键两种状况答复。 国际惯例，先上张脑图： 02 有主键如果你的表有主键，并且把主键设置为自增。 在 MySQL 中，个别会把主键设置成 int 型。而 MySQL 中 int 型占用 4 个字节，作为有符号位的话范畴就是 [-2^31,2^31-1]，也就是[-2147483648,2147483647]；无符号位的话最大值就是 2^32-1，也就是 4294967295。 上面以有符号位创立一张表： CREATE TABLE IF NOT EXISTS t(id INT(11) NOT NULL AUTO_INCREMENT,url VARCHAR(64) NOT NULL, PRIMARY KEY ( id ))ENGINE=InnoDB DEFAULT CHARSET=utf8;复制代码插入一个 id 为最大值 2147483647 的值，如下图所示： 如果此时持续上面的插入语句： INSERT INTO t (url) VALUES ('wwww.javafish.top/article/erwt/spring')复制代码后果就会造成主键抵触： 2.1 解决方案虽说 int 4 个字节，最大数据量能存储 21 亿。你可能会感觉这么大的容量，应该不至于用完。然而互联网时代，每天都产生大量的数据，这是很有可能达到的。 所以，咱们的解决方案是：把主键类型改为 bigint，也就是 8 个字节。这样能存储的最大数据量就是 2^64-1，我也数不清有多少了。反正在你有生之年应该是够用的。 PS：单表 21 亿的数据量显然不事实，一般来说数据量达到 500 万就该分表了。 ...

本文首发：《MySQL「 Every derived table must have its own alias」1248 谬误修复法》 在写带有子查问或者在查问时产生长期表的查问时，可能会呈现这个谬误： ERROR 1248 (42000): Every derived table must have its own alias意思是「每一个派生进去的表都必须给它命名一个本人的别名」 咱们看个例子： 假如有一张「顾客购买记录」的表 - kalacloud_purchases 记录了顾客在商店购物的信息。咱们要写个查问，查看哪些客户在多个商店买过货色： SELECT DISTINCT customer_id, SUM(1) FROM ( SELECT DISTINCT customer_id, store_id FROM kalacloud_purchases) GROUP BY customer_id HAVING 1 < SUM(1); 运行后，能够看到呈现 1248 谬误：Every derived table must have its own alias 在这段报错代码中： FROM ( SELECT DISTINCT customer_id, store_id FROM kalacloud_purchases)这段命令会先查 kalacloud_purchases 表，而后生成一张新的长期表，如果这个长期表没有命名，就会导致 1248 谬误。咱们只须要加上 「as 长期表别名」即可修复谬误 加上「AS customer」别名， 这样就解决了这个问题。 ...

本文首发：MySQL only_full_group_by 1055报错的三种解决方案，长期敞开有影响吗？ 当咱们迁徙到 MySQL 5.7+ 的版本时，常会碰到 ERROR 1055 only_full_group_by 谬误，这是 5.7 之后 SQL_MODE 默认关上了严格模式导致的谬误。阐明你代码里有中央写的不谨严。 ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'kalacloud.user_id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by我看到大多数教程，只写了解决这个问题「术」的局部，并没有解说什么起因导致这个谬误。本教程先从原理讲起，先让大家了解为什么会出错。而后给出三种解决方案：「彻底解决」、「长期解决」和「折中解决」，你可依据本人的理论状况进行抉择。 SQL_MODE 是什么？讲 ONLY_FULL_GROUP_BY 谬误前，咱们先来说一下 SQL_MODE。了解 MySQL 工作原理能更好的帮你了解谬误产生的实质起因。 SQL_MODE 是 MySQL 中的一个环境变量，定义了 MySQL 反对的 SQL 语法和数据校验水平。 SQL_MODE 一共三种模式 ANSI 模式：宽松模式。对插入数据进行校验，如不合乎定义类型或长度，对保留数据进行截断。TRADITIONAL 模式：严格模式。对插入数据进行严格校验，保障谬误数据不能插入，ERROR 报错。用于事物时，事物会进行回滚。STRICT_TRANS_TABLES 模式：严格模式。对插入数据进行严格校验，谬误数据不能插入，ERROR 报错。MySQL 5.7.4 之前，MySQL 默认不开启严格模式 这是 MySQL 降级到5.7.5 之后默认SQL_MODE 为严格模式： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答问题运行上面的这段Python代码，却总是无奈更新数据： import pymysqlconn=pymysql.connect(host = '127.0.0.1', user = 'yewen', passwd='YeWen.3306',port= 3306, db='test', charset='utf8mb4')cur = conn.cursor()sql = "update t1 set c3 = rand()*10240 where c1 = rand()*1024"cur.execute(sql)cur.close()conn.close()而运行上面的这段看起来一样的代码，却能够失常删表：import pymysqlconn=pymysql.connect(host = '127.0.0.1', user = 'yewen', passwd='YeWen.3306',port= 3306, db='test', charset='utf8mb4')cur = conn.cursor()sql = "drop table tmp1"cur.execute(sql)cur.close()conn.close()答复其实问题并不简单，有几个起因： 1.要写入的表是InnoDB引擎，而InnoDB引擎是反对事务的，也就是写入后，要提交事务才是真正实现写入。2.连贯数据库时，须要自行设定事务主动提交模式，是开启还是敞开。3.pymysql模块里，默认不启用主动提交模式。所以对表进行DML操作时，须要提交事务后能力胜利。4.而删除表是DDL操作，目前DDL操作还不反对事务，所以即使没有开启主动提交，也能胜利。晓得下面的起因就好办了。咱们先看下pymysql源码中对于主动提交的设定： [root@yejr-mgr1 pymysql]# cat /usr/lib/python2.7/site-packages/pymysql/connections.py...#约158行左近 158 :param autocommit: Autocommit mode. None means use server default. (default: False)...所以，解决办法有好几种： 在连贯初始化时开启主动提交模式，例如：#设置属性autocommit=1亦可conn=pymysql.connect(host = '127.0.0.1', user = 'yewen', passwd='YeWen.3306',port= 3306, db='test', charset='utf8mb4', autocommit=True)或者执行完DML操作后，再执行一次commit申请，例如：sql = "update t1 ...cur.execute(sql)cur.execute("commit")又或者在创立完连贯后，批改autocommit模式，例如：conn=pymysql.connect(host = '127.0.0.1', user = 'yewen', passwd='YeWen.3306',port= 3306, db='test', charset='utf8mb4')cur = conn.cursor()cur.execute("set autocommit=1")到这里，主动提交的问题解决了。 ...

明天想跟大家聊聊数据库层面上的事 注：明天聊的数据库都特指关系型数据库 01、数据库抉择之前发了一张我可能要在austin我的项目上引入哪些技术栈的图，好多人问我分布式配置核心为什么不抉择Nacos，而是用Apollo。却没人问我为什么数据库抉择MySQL。 说起来MySQL，在网上看到的各类Java教程，简直都是应用MySQL作为数据库。日常在群里聊各种数据库上的问题，也差不多都是MySQL，只有个别的可能用PostgreSQL和Oracle或其余 就连我在面试的时候，我也没被面试官问过：“你的数据库为什么抉择MySQL啊？这块技术选型是怎么样的” 看到这里，是不是感觉我有答案了？其实我也没有。写到一半的时候发现我也说不出啥比拟好的理由...既然我不晓得，于是我就去看看人家是怎么说的。 总结起因可能是： 后期MySQL收费开源易用，从泛滥厂商中硬生生搞出了生态。有了生态，很难就被干掉了。（最次要的）互联网用MySQL就是用来存数据“低成本疾速的数据存储插入计划”，要求也绝对没那么高（这条我前面会具体聊聊）很多时候对某技术选型并非是技术起因 而我，我只会MySQL。我在生产环境下只用过MySQL，当年我还是小白的时候接触过Oracle，但当初也根本忘得差不多了。 很多时候对某技术选型并非是技术起因（我是懒狗，我抵赖了）。近几年PostgreSQL很火，据说很多中央都比MySQL要好，感兴趣的小伙伴能够把austin我的项目的MySQL替换为PostgreSQL 对数据库选型感兴趣的大哥们也能够找点材料持续查阅材料，也很欢送在评论区输入下本人的教训，这种话题探讨我感觉还是蛮有意思的。 跟着我一起做austin我的项目的小伙伴应该对关系型数据库都有所理解了，这里的根底我就不开展讲述了。对MySQL感兴趣或者筹备要面试的同学，能够看看我《对线面试官》系列的MySQL章节（在各大博客平台中受到了不错的反馈） 02、ORM框架抉择记得几年前我刚接触数据库和Java的时候，那时候要用JDBC连贯数据库来操作数据，我就很不解：明明我能够通过各种的数据库客户端就能对数据进行操作，为啥我要用JDBC，好麻烦啊！ 至于为什么会有这种疑难，我也不了解我过后是怎么想的（哈哈哈哈）。起初想通了当前，也学习了很多在程序上“简化JDBC模板”的姿态（DBUtils/Hibernate/Spring JDBC/Mybatis/SpringData JPA) 我在生产环境中接触过的都是Mybatis，但这一次我在asutin我的项目中决定应用SpringData JPA作为ORM框架。 03、应用数据库的教训这两年我是呆在互联网公司下班的，我就来聊下我集体所接触到的货色，分享下我的认识。 一般来说，每个业务团队保护着本人的数据库（一个业务团队可能就有好几个库），当咱们须要某一个团队的相干数据时，团队会提供对应的RPC接口给公司外部业务应用。 这意味着数据逻辑对调用业务方而言，是通明的（调用业务方不须要关注其余团队数据库的任何信息，无论是数据库表设计还是具体的字段）。 这个益处是显然地：要某团队的业务数据，只有找到他们提供的接口就完事了。作为需求方，只须要调个接口就能拿到本人想要的数据。 回到数据库外部存储自身，咱们会尽可能将表结构设计得更简略：在很多状况下，都会放弃数据库三大范式来设计表。 举个很简略又可能不太失当的场景：一个作者可能会写多篇文章（意味着多篇文章会属于同一个作者） author:content(1:N) 那在初学的时候，可能有的教程会这样设计：author表、content表、autor_content_mapping表 然而，咱们在理论中生产环境中很有可能是不设计这种关联表，而是间接把相干字段冗余在一张表里。这样在查问的时候，就能间接通过一张表查到对应的信息了，不必进行多层关联 如果按下面的构造进行查问：比方我要查到某一篇文章的作者根本信息，那我此时的动作是： 关联author_content表查到文章的authorId通过authorId去author表查到作者的根本信息如果我把authorId间接存到content表中，那就意味着少了去author_content表查问了。 注：这里我不是说让你们把所有的信息都存在一张表里，一张表里有上百个字段，千万不要误会我的意思！ 说起关联，又有一个能聊的话题：是否join（这个话题我已经在我的交换群中聊过，不过也是各抒所见吧）。我在以前公司接触到的我的项目，在mapper.xml中都看不到join的身影，我写join只在hive写统计脚本的时候用到。 【强制】超过三个表禁止 join。须要 join 的字段，数据类型必须相对统一；多表关联查问时，保障被关联的字段须要有索引。 阐明：即便双表 join 也要留神表索引、SQL 性能。 我总结了一份：mysql性能优化和高可用架构实战，点此收费下载 喜爱用join的会通知你：我写join会让代码变得更简略。查数据太麻烦了，要查的数据会存到多张表里，间接在用join的开发效率是最快的！ 而我，我是反对在代码里写业务逻辑的。所有都是单表查问，在程序代码中对数据进行关联（数据库的JOIN无能到的事，在程序上肯定无能失去）。这样的益处就在于：SQL简略，SQL易复用，SQL易优化 在绝大数状况下，咱们的接口瓶颈都是来源于「数据库」，而非应用服务器。多JOIN且简单的SQL是不好优化的，而简略的SQL是比拟好优化的，并且我认为程序逻辑往往都要比SQL更容易保护。 在我这两年在互联网公司中，关系型数据库在我的认知里，它就是作为一个反对事务的存储。如果咱们存储的数据对事务没有要求的，可能压根就不须要存储至关系型数据库中。 当初数据源可抉择的太多了，咱们能够把数据存储到Redis(内存数据库)、Elasticsearch（搜索引擎）、HBase（分布式、可伸缩的大数据存储）、HDFS（分布式文件系统）、clickhouse（OLAP存储系统）等等等 基于下面这些背景下，我的查问SQL就不会简单，那么Spring Data JPA不就很适宜我了么？ 04、开发之外的数据库去到有肯定规模的公司，都会有数据库相干的根底建设，上面提下常见的根底建设吧 一、DDL和DML都须要走工单 生产环境的数据库实践都不能通过本人编写接口在程序中批改（高危动作），须要修数据或者建表都须要通过工单零碎审核（个别是数据库负责人+DBA） 比方你提交建表申请，DBA会看你的表设计是否正当（是否有加索引等等） 二、DQL查问线上数据须要权限 咱们要查问线上的数据，个别都得申请库的权限，有了权限之后在公司内网特定的页面进行数据查问（咱们个别只须要查团队内的数据，所以其实也还好，其余团队的数据库权限是不凋谢的，要数据个别只能通过接口获取） 三、程序上个别不直连数据库（会有代理层） 个别只有线下数据库能够通过ip直连，线上数据库都会通过代理层（代理层能够做很多货色，包含监控鉴权分库分表等等） 四、齐备的监控告警 数据库作为一个很重要的存储之一（如果挂了是真的影响很大），会有齐备的监控和告警。比如说执行SQL失败的告警、执行慢SQL的告警等等，对数据库的各种指标进行实时监控 ...

前言innodb_buffer_pool_size能够调大，却不能调小至1GB以内，这是为什么？MySQL 版本：5.7.30 测试环境有台 MySQL 服务器反馈很慢，查看零碎后发现内存使用量已超过90%，并且有大量的SWAP占用： 运行top按内存占用排序，查看系统资源应用状况 能够看到内存占用最多的是java过程和4个mysqld过程。 因为短期内无奈加内存，java内存大小利用不让调整，那就只能想方法压缩mysqld应用的内存大小了。 这台服务器部署了4个 MySQL 实例，其中两个是轻量级利用，数据量非常少，但过后创立的时候配置文件应用的是雷同的配置，所以先拿这两个开刀。 执行上面的命令查看以后innodb buffer pool值 mysql>show global variables like 'innodb_buffer_pool%'; 给调配1GB，并不算大（服务器内存16G），但这个实例里交易量和数据量都很小，先试试砍半吧。 从MySQL 5.7开始，innodb_buffer_pool_size必须等于innodb_buffer_pool_chunk_size *innodb_buffer_pool_instances的整数倍才行，详见官网阐明（https://dev.mysql.com/doc/ref...）。 mysql>set global innodb_buffer_pool_size=13421772822; 没想到，竟然报错了！难道是BUG？试试调大innodb_buffer_pool_size mysql>set global innodb_buffer_pool_size=13421772825; 调大不报错，正百思不得其解，经共事点播，可能是 innodb_buffer_pool_instances 的设置值导致的（官网形容 innodb_buffer_pool_instances 必须在 innodb_buffer_pool_size 大于等于 1G 时才失效），也就是说： 因为innodb_buffer_pool_instances 值为 2，因而 innodb_buffer_pool_size必须大于1GB。为印证猜想，将innodb_buffer_pool_instances改成1，批改配置文件后重启实例，查看innodb_buffer_pool相干变量值 能够看到innodb_buffer_pool_instances已变成1，再次调低 innodb_buffer_pool_size mysql>set global innodb_buffer_pool_size=13421772814; 这次设置胜利了，阐明咱们的猜想是正确的。 总结及倡议当 innodb_buffer_pool_size 值低于 1GB时，没必要也不能设置 innodb_buffer_pool_instances 值大于等于 2。一般而言，当 innodb_buffer_pool_size 值不高于 8GB时，没必要设置 innodb_buffer_pool_instances 值大于 1。通常，当 innodb_buffer_pool_size 较大时（大于64GB），innodb_buffer_pool_instances 设置为 8 是个比拟正当的值。Enjoy MySQL :) ...

1，执行过程![上传中...]() 2，执行程序![上传中...]() mysql执行过程和程序

万答#11，MySQL中char与varchar有什么区别 1.试验场景GreatSQL 8.0.25 InnoDB 2.试验测试2.1 区别参数charvarchar长度是否可变定长变长存储容量0 ~ 2550 ~ 65,5352.2 建测试表CREATE TABLE vc (v VARCHAR(4), c CHAR(4));2.3 未超出设定值测试字段V、C都写入一个4+空格的字符 [root@GreatSQL][test]> INSERT INTO vc VALUES ('4 ', '4 ');[root@GreatSQL][test]> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;+---------------------+---------------------+| CONCAT('(', v, ')') | CONCAT('(', c, ')') |+---------------------+---------------------+| (4 ) | (4) |+---------------------+---------------------+1 rows in set (0.00 sec)测试后果，char的长度维持不变，占了2个字符，varchar空格长度变了，占了一个字符。 2.4 超出设定值测试当写入长度大于设定长度时候，呈现报错 [root@GreatSQL][test]>INSERT INTO vc VALUES ('123456', '123456');ERROR 1406 (22001): Data too long for column 'v' at row 1调整sql_mode，再写入的时候，主动截取限度容量内的内容 ...

转载自：https://www.cnblogs.com/lingl... 一 装置前筹备1、查看是否曾经装置过mysql，执行命令 rpm -qa | grep mysql如果已存在，则执行删除命令 后边为Mysql目录 rpm -e --nodeps mysql-xxxx2、查问所有Mysql对应的文件夹 whereis mysqlm find / -name mysql 删除相干目录或文件 rm -rf /usr/bin/mysql /usr/include/mysql /data/mysql /data/mysql/mysql验证是否删除结束 whereis mysqlm find / -name mysql 3、查看mysql用户组和用户是否存在，如果没有，则创立 cat /etc/group | grep mysql cat /etc/passwd |grep mysql groupadd mysql useradd -r -g mysql mysql 二 装置Mysql1 - 从官网下载是用于Linux的Mysql安装包下载命令： wget https://dev.mysql.com/get/Dow...执行解压命令： tar xzvf mysql-5.7.24-linux-glibc2.12-x86_64.tar.gz解压实现后，能够看到当前目录下多了一个解压文件，挪动该文件到/usr/local/下，并将文件夹名称批改为mysql。(如果/usr/local/下曾经存在mysql，请将已存在mysql文件批改为其余名称，否则后续步骤可能无奈正确进行。) 执行命令如下： mv mysql-5.7.24-linux-glibc2.12-x86_64 /usr/local/mysql2 - 在/usr/local/mysql目录下创立data目录 mkdir /usr/local/mysql/data3 - 更改mysql目录下所有的目录及文件夹所属的用户组和用户，以及权限 chown -R mysql:mysql /usr/local/mysqlchmod -R 755 /usr/local/mysql如果报以上谬误，阐明mysql用户不存在，执行以下命令，操作完再执行更改权限命令 ...

共事反馈一个问题：Mybatis插入数据库的工夫是昨天的，是不是因为生成Mybatis逆向工程生成的代码有问题？ 大家都晓得，对于这类Bug自己是很感兴趣的。直觉通知我，应该不是Mybatis的Bug，很可能是时区的问题。 很好，明天又能够带大家一起来排查Bug了，看看从这次的Bug排查中你能Get什么技能。 这次钻研的问题有点深奥，但论断很重要。Let's go! 问题猜测共事反馈问题的时候，带了本人的猜测：是不是数据库字段设置为datetime导致？是不是Mybatis逆向工程生成的代码中类型不统一导致的？ 共事还要把datetime改为varchar……马上被我禁止了，说：先排查问题，再说解决方案，下午我也抽时间看看。 问题核查第一步，查看数据库字段类型，是datetime的，没问题。 第二步，查看实体类中类型，是java.util.Date类型，没问题。 第三步，Bug复现。 在Bug复现这一步，用到了单元测试。话说之前还跟敌人探讨过单元测试的魅力，当初自己是越来越喜爱单元测试了。 我的项目基于Spring Boot的，单元测试如下（代码已脱敏）： @SpringBootTestclass DateTimeTests { @Resource private UserMapper userMapper; @Test public void testDate(){ User user = new User(); // 省略其余字段 user.setCreateDate(new Date()); userMapper.insertSelective(user); }}执行单元测试，查看数据库中插入的数据。Bug复现，工夫确实是前一天的，与以后工夫相差14个小时。 通过下面三步的排查，核实了数据库字段和代码中类型没问题。单元测试也复现了问题，共事没有坑骗我，总要眼见为实，哈哈~ 于是根本确定是时区问题。 时区排查查看服务器工夫登录测试服务器，执行date命令，查看服务器工夫和时区： [root@xxx ~]# date2021年 11月 25日 星期四 09:26:25 CST[root@xxx ~]# date -RThu, 25 Nov 2021 09:33:34 +0800显示工夫是以后工夫，采纳CST工夫，最初的+0800，即东8区，没问题。 查看数据库时区连贯数据库，执行show命令： show variables like '%time_zone%';+----------------------------+|Variable | Value |+----------------------------+|system_time_zone |CST ||time_zone |SYSTEM |system_time_zone：全局参数，零碎时区，在MySQL启动时会查看以后零碎的时区并依据零碎时区设置全局参数system_time_zone的值。值为CST，与零碎工夫的时区统一。 time_zone：全局参数，设置每个连贯会话的时区，默认为SYSTEM，应用全局参数system_time_zone的值。 查看代码中时区在单元测试的办法内再增加打印时区的代码： @Test public void testDate(){ System.out.println(System.getProperty("user.timezone")); User user = new User(); // 省略其余字段 user.setCreateDate(new Date()); userMapper.insertSelective(user); }打印的时区为： ...

旧的数据库无奈撑持了，所以公司买了一个新的服务器弄数据库。然而因为旧的数据须要迁徙。然而迁徙的过程中，有个共事因为谬误形式导致整个库局部数据被替换。 他将所应用的数据库，右键点击转存SQL文件，而后间接将这个SQL文件拉近新的数据库中（间接拉入新的链接之内，没有新建数据库）。导致那个SQL文件全局失效了，如果有同名的表，会间接进行笼罩，而且会在每个数据库中创立SQL文件所贮存的表。 幸好是新的数据库并且是测试环境，不然就。。。。。。。 也引起一些技术疑难，如何疾速迁徙数据库的文件。如果这个数据库是不同类型的话，如何进行迁徙呢？

mysql将表构造导出excelSELECT COLUMN_NAME 列名, COLUMN_TYPE 数据类型, DATA_TYPE 字段类型, CHARACTER_MAXIMUM_LENGTH 长度, IS_NULLABLE 是否为空, COLUMN_DEFAULT 默认值, COLUMN_COMMENT 备注 FROM INFORMATION_SCHEMA.COLUMNSwheretable_schema ='数据库名称'AND-- 如果不写的话，默认会查问出所有表中的数据，这样可能就分不清到底哪些字段是哪张表中的了，所以还是倡议写上要导出的名名称table_name = '表名称'

MySQL的锁实现乐观锁 乐观锁 （ Pessimistic Locking ），总是会很乐观的认为，每次去读数据的时候都认为他人会批改，所以每次在读数据的时候都会上锁， 这样他人想读取数据就会阻塞直到它获取锁 (共享资源每次只给一个线程应用，其它线程阻塞，用完后再把资源转让给其它线程)。 传统的关系型数据库里边就用到了很多乐观锁机制，比方行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。乐观锁乐观锁（ Optimistic Locking ），总是会乐观的认为，每次去读数据的时候都认为他人不会批改，所以不会上锁， 然而在更新的时候会判断一下在此期间有没有其余线程更新该数据， 能够应用版本号机制和CAS算法实现。 乐观锁实用于多读的利用类型，这样能够进步吞吐量。 CAS是英文单词Compare and Swap的缩写，翻译过去就是比拟并替换。CAS机制中应用了3个根本操作数：内存地址V，旧的预期值A，要批改的新值B。更新一个变量的时候，只有当变量的预期值A和内存地址V当中的理论值雷同时，才会将内存地址V对应的值批改为B。乐观锁应用创立一个数据库 DROP DATABASE IF EXISTS locktest;CREATE DATABASE locktest;USE locktest;DROP TABLE IF EXISTS warehouse;CREATE TABLE IF NOT EXISTS warehouse ( id INTEGER NOT NULL, stock INTEGER DEFAULT 0, version INTEGER DEFAULT 1, PRIMARY KEY (id)) ENGINE = INNODB;INSERT INTO warehouse VALUE (1, 200, 1);SELECT * FROM warehouse;idstockversion12001关上2个MySQL终端，并敞开主动提交：set autocommit = 0; autocommit 只对反对事务的引擎起作用，如InnoDB，默认状况下autocommit的值为1，MySQL默认对写操作会主动开启事务，autocommit = 1时会在操作执行commit提交操作set autocommit = 0;第1个终端执行查问 这里咱们应用for update关键字给表上锁 ...

发现连不上数据库了。报错,解决方案，亲测无效 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' 很显著是mysql.sock文件找不到了，这个文件以前在/tmp 下当初没有了，那么怎么办呢？重启一下mysql 服务就会本人生成吧。 我的mysql 是 很早以前用 homebrew 装置的，所以启动就 cd /usr/local/Cellar/mysql/5.7.19sudo ./support-files/mysql.server start如果启动报错： . ERROR! The server quit without updating PID file (/usr/local/var/mysql/bogon.pid)则可能是没有bogon/没有权限，咱们给予权限即可 sudo chmod -R 777 /usr/local/var/mysql/ 启动后发现tmp 下就有了一个mysql.sock ，再连贯数据库。ok 连贯胜利

一、前言只有InnoDB引擎反对事务，下边的内容均以InnoDB引擎为默认条件 二、常见的并发问题1、脏读一个事务读取了另一个事务未提交的数据 2、不可反复读一个事务对同一数据的读取后果前后不统一。两次读取两头被其余事务批改了 3、幻读幻读是指事务读取某个范畴的数据时，因为其余事务的操作导致前后两次读取的后果不统一。幻读和不可反复读的区别在于,不可反复读是针对确定的某一行数据而言,而幻读是针对不确定的多行数据。因此幻读通常呈现在带有查问条件的范畴查问中 三、事务隔离级别1、读未提交(READ UNCOMMITTED)可能产生脏读、不可反复读、幻读 2、读已提交(READ COMMITTED)防止了脏读，可能产生不可反复读、幻读 3、可反复读(REPEATABLE READ)（mysql默认隔离级别）防止了脏读，不可反复读。通过区间锁技术防止了幻读 4、串行化(SERIALIZABLE)串行化能够防止所有可能呈现的并发异样,然而会极大的升高零碎的并发解决能力 四、数据库日志有哪些？1、undo日志undo日志用于存放数据批改被批改前的值 UNDO LOG中分为两种类型，一种是 INSERT_UNDO（INSERT操作），记录插入的惟一键值； 一种是 UPDATE_UNDO（蕴含UPDATE及DELETE操作），记录批改的惟一键值以及old column记录。 2、redo日志mysql会将一个事务中的所有sq先l记录到redo log中，而后再将记录从redo log同步到数据文件中 它能够带来这些益处： 当buffer pool中的dirty page 还没有刷新到磁盘的时候，产生crash，启动服务后，可通过redo log 找到须要从新刷新到磁盘文件的记录；buffer pool中的数据间接flush到disk file，是一个随机IO，效率较差，而把buffer pool中的数据记录到redo log，是一个程序IO，能够进步事务提交的速度；3、binlog日志用于数据库主从复制的记录，是二进制格局。在事务提交之后进行一个磁盘写入。 这里留神下redo log 跟binary log 的区别，redo log 是存储引擎层产生的，而binary log是数据库层产生的。假如一个大事务，对tba做10万行的记录插入，在这个过程中，始终一直的往redo log程序记录，而binary log不会记录，直到这个事务提交，才会一次写入到binary log文件中 五、数据库事务管制1、默认状况下，开启事务主动提交性能。每执行一个sql，都会对应一个事务的提交 2、spring会将底层连贯的主动提交个性设置为false。应用手动提交 六、事务的ACID个性1、原子性(Atomicity)事务中的所有操作作为一个整体像原子一样不可分割，要么全副胜利,要么全副失败。 2、一致性(Consistency)java培训中事务的执行后果必须使数据库从一个一致性状态到另一个一致性状态。一致性状态是指:1.零碎的状态满足数据的完整性束缚(主码,参照完整性,check束缚等) 2.零碎的状态反馈数据库本应形容的事实世界的实在状态,比方转账前后两个账户的金额总和应该放弃不变。 3、隔离性(Isolation)并发执行的事务不会相互影响,其对数据库的影响和它们串行执行时一样。比方多个用户同时往一个账户转账,最初账户的后果应该和他们按先后秩序转账的后果一样。 4、持久性(Durability)事务一旦提交,其对数据库的更新就是长久的。任何事务或系统故障都不会导致数据失落。 5、redo log和undo log实现了原子性、一致性、持久性 6、锁机制实现了隔离性6.1、快照读读取的是快照版本，也就是历史版本。一般的SELECT就是快照读 6.2、以后读读取的是最新版本。UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE是以后读。 6.3、锁定读　在一个事务中，规范的SELECT语句是不会加锁，然而有两种状况例外。SELECT … LOCK IN SHARE MODE 和 SELECT … FOR UPDATE。 ...

一、表级锁、行级锁、页级锁数据库锁定机制简略来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发拜访变得有序所设计的一种规定。 MySQL 数据库因为其本身架构的特点，存在多种数据存储引擎，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。 MySQL 各存储引擎应用了三种类型（级别）的锁定机制：表级锁定，行级锁定和页级锁定。 1、表级锁 表级别的锁定是 MySQL 各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的零碎负面影响最小。所以获取锁和开释锁的速度很快。 当然，锁定颗粒度大所带来最大的负面影响就是呈现锁定资源争用的概率也会最高，以致并发度大打折扣。 应用表级锁定的次要是 MyISAM，MEMORY，CSV 等一些非事务性存储引擎。 2、行级锁 行级锁定最大的特点就是锁定对象的颗粒度很小，因为锁定颗粒度很小，所以产生锁定资源争用的概率也最小，可能给予应用程序尽可能大的并发解决能力而进步一些须要高并发利用零碎的整体性能。 尽管可能在并发解决能力下面有较大的劣势，然而行级锁定也因而带来了不少弊病。 因为锁定资源的颗粒度很小，所以每次获取锁和开释锁须要做的事件也更多，带来的耗费天然也就更大了。此外，行级锁定也最容易产生死锁。 应用行级锁定的次要是InnoDB存储引擎。 3、页级锁 页级锁定是 MySQL 中比拟独特的一种锁定级别。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所须要的资源开销，以及所能提供的并发解决能力也同样是介于下面二者之间。 应用页级锁定的次要是 BerkeleyDB 存储引擎。 4、总结 总的来说，MySQL 这 3 种锁的个性可大抵归纳如下： 表级锁：开销小，加锁快；不会呈现死锁；锁定粒度大，产生锁抵触的概率最高，并发度最低； 行级锁：开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低，并发度也最高； 页面锁：开销和加锁工夫界于表锁和行锁之间；会呈现死锁；锁定粒度界于表锁和行锁之间，并发度个别。 二、共享锁、排它锁InnoDB 实现了规范的行级锁，包含两种：共享锁（简称 s 锁）、排它锁（简称 x 锁）。 对于共享锁而言，对以后行加共享锁，不会阻塞其余事务对同一行的读申请，但会阻塞对同一行的写申请。只有当读锁开释后，才会执行其它事物的写操作。 对于排它锁而言，会阻塞其余事务对同一行的读和写操作，只有当写锁开释后，才会执行其它事务的读写操作。java培训 简而言之，就是读锁会阻塞写(X)，然而不会梗塞读(S)。而写锁则会把读(S)和写(X)都梗塞 对于 InnoDB 在 RR(MySQL 默认隔离级别) 而言，对于 update、delete 和 insert 语句， 会主动给波及数据集加排它锁（X）； 对于一般 select 语句，innodb 不会加任何锁。如果想在 select 操作的时候加上 S 锁 或者 X 锁，须要咱们手动加锁。 -- 加共享锁（S）select * from table_name where ... lock in share mode ...

阿里云官网镜像站：MySQ镜像源 https://developer.aliyun.com/... 前言MySQL是最风行的数据库之一，在大多零碎的后端的存储都有MySQL的身影，MySQL运行的是否衰弱，间接影响着整个零碎的运行，数据库的瓶颈往往也是整个零碎的瓶颈，其重要性显而易见，所以对于MySQL的监控必不可少，及时发现MySQL运行中的异样，能够无效进步零碎的可用性和用户体验。本文次要介绍下MySQL如何做监控，以及对Datadog的Database Monitoring的一些简略调研。 监控类型Google提出在系统监控中的黄金指标，别离是Latency，Traffic，Saturation，Errors，MySQL个别作为资源类服务零碎呈现，在MySQL监控中也能够以这些指标为指引来进行指标收集和监控。 黄金指标Latency提早：比方MySQL中的查问的提早，一条Select语句的提早可能会间接影响用户体验，监控SQL语句的均匀提早，P99提早能够提前发现对系统的影响。Traffic：在MySQL中，查问的QPS是吞吐量的一种指标，比方MySQL服务器每秒能够反对多少查问，多少更新，吞吐量的指标也会影响到用户体验。Saturation饱和度：饱和度是指零碎的资源被耗费殆尽的水平，比方在MySQL最大连接数为300，以后连接数曾经达到240的状况可能须要引起留神，因为可能在不久的未来会将连接数打满，导致新的连贯进不来，影响下层服务的可用性。Errors谬误：MySQL中的Aborted_clients和Aborted_connects的减少往往象征了应用方在应用的时候呈现了一些谬误，须要引起留神，比方客户端在退出时没有调用mysql_close会导致Aborted_clients指标的减少，所以监控这个指标对于问题的排查很有帮忙。 MySQL要害指标类型黄金指标对于指标的监控有很大的指导意义，然而选取哪些指标，也是值得考量的，这里借用Datadog的一篇MySQL监控文章来形容MySQL监控中的要害指标。从性能和资源应用角度大抵分为4类： • Query throuput：查问吞吐量，次要包含查问的QPS和更新QPS，用来示意提早。 • Query performance: 查问性能，次要包含查问的耗费的均匀工夫，查问谬误指标，慢查问数量，别离蕴含吞吐量和谬误。 • Connections: 连贯，次要包含以后关上连接数和运行连接数示意饱和度。谬误连接数用来示意谬误。 • Buffer pool usage: 缓冲池应用状况，innodb_buffer_pool_reads示意InnoDB缓冲池无奈满足的申请数，计算出的缓冲池中的页面应用数量使用率能够用示意资源的饱和度。 MySQL监控流程MySQL的监控跟其余零碎的监控相似，个别会蕴含指标日志类的数据收集，指标的可视化展现，指标告警，问题的排查等流程。 指标收集MySQL的指标类型有很多，能够通过两种形式获取 • 服务外部状态/外部变量：个别通过show status或者show variable来获取，示意全局的一些指标。 • peformance shema和sys schema，提供了更加底层的运行时的具体的指标信息。 可视化展现通过Agent将指标数据采集到后端存储中，而后进行可视化展现，可视化仪表盘会将指标的历史值和以后值绘制成曲线，便于查看指标的变动，指标如果有显著的变动，从图表中能够显著的看进去，对于排查问题有肯定的参考意义。 指标异样告警在某个指标出现异常时，能够配置相应的告警，告警监控能够应用阈值设定或者AI算法来自动识别指标的异样，产生的告警能够分不同的重大等级，不同的等级能够配置不同的告诉渠道，比方重大度低的发邮件揭示既能够，对于高重大度的指标异样，配置电话告诉。通过仪表盘或者告警，能够找到哪个指标呈现了异样，而后依据不同的指标进行不同的排查形式，比方连接数超过最大连接数报警，能够调大数据库的最大连接数或者缩小客户端的连接数。对于更简单的场景，可能须要借助问题产生时其余的日志或者指标进行根因剖析。 接下来以Datadog的数据库监控为例，来调研Datadog是如何做数据库监控的，文中图片来自Datadog官网。 Datadog 数据库监控指标采集Agent端采集Datadog的指标采集是通过装置Agent来采集，Agent能够部署在自建机器或者云服务器上，能够连贯到服务器即可。 指标数据通过装置Datadog Agent到数据库所在服务器或者能连贯到数据的服务器上，而后创立一个datadog用户，并且给datadog赋予肯定的权限如REPLICATION CLIENT，PROCESS和SELECT ON performance_schema.*的权限。Datadog为了收集explain plan还会创立几个存储过程explain_statement，enable_events_statements_consumers。 日志数据Datadog Agent反对采集MySQL服务器端General日志、谬误日志、慢日志等，当然前提是MySQL服务端开启这些日志存储。 仪表盘总体指标MySQL总览，次要展现了收集的MySQL指标的整体态势。 Query Metrics次要用来展现标准化查问（normalized query）的历史性能指标，能够依照查问数，均匀提早，耗费总工夫，返回行数进行排序。同时也能够依据标签或聚合维度来展现耗费了最多查问工夫的Top查问和提早。依据不同的维度来分组展现每个组的查问数，均匀提早，耗费总工夫。 Query Details在Query Metrics页面搜寻特定的query，能够查看其Query Detail页面，在其中能够查看语句的均匀提早和查问总工夫，同时页面还会展现查问关联的Datadog中标签， 查问页面除了提早和耗费工夫等，还会展现执行打算，时序和执行这条查问的主机散布。 • 执行打算页面，会展现不同的执行打算及其提早和均匀耗费。 • 性能指标页面，展现了一些常见指标的性能历史。 • 执行查问的主机散布页面，会展现执行以后查问的主机散布，通过菜单能够链接到主机的相干页面，这对于排查问题比拟不便，比方某个主机上的查问提早十分高，能够间接跳转到改主机的相干仪表盘页面进行查看。 Query Samples次要蕴含采样查问的性能数据，提早，耗费和执行打算，同时也反对依照Table来展现Top耗费的查问语句。 告警Datadog提供了对于指标的监控告警，次要反对五种监控类型，包含： • Thresold Alert：阈值监控。 • Change Alert: 事件变更监控。 ...

1 - 查看以后Mysql存储目录连贯到MySQL输出查问目录命令 SHOW VARIABLES LIKE '%datadir后果相似 Variable_name Value ------------- ---------------- datadir C:\ProgramData\MySQL\MySQL Server 8.0\Data\2 - 批改目录进行MySQL服务把 "C:\ProgramData\MySQL\MySQL Server 8.0\Data\" 中的Data目录内容，复制到想要存储的新地位Data同级目录中，找到my.ini。批改 datadir="自定义目录"，保留。3 - 确认目录批改启动MySQL服务输出查问目录命令,确认目录为新目录。异常情况本地计算机 上的MySQL80服务启动后进行。某些服务在未由其余服务或程序应用时将主动进行。 如下 起因可能是Mysql对新的目录的权限不够。须要赋予以后系统对该文件夹足够的权限才行。右键Data文件夹属性 ---> 平安选项 ---> 抉择以后登陆账户 ---> 编辑 勾选齐全管制 ---> 利用 ---> 确定 此时再次启动，胜利. 如果还不能胜利，用my.ini中的门路复制到文件夹门路中，查看是否正确达到指定地位。

万答10：mysqldump 是如何实现一致性备份的 试验场景MySQL 8.0.25 InnoDB 试验步骤：先开启 general_log 察看导出执行过程的变动 set global general_log=ON;mysqldump 要害参数阐明： --single-transaction 参数阐明： 将隔离级别设为 REPEATABLE READ ， 并开启一个只读事务，该事务中会进行一致性快照读，这个选项对InnoDB的数据表无效，然而不能保障MyISAM表和MEMORY表的数据一致性，dump 操作期间会先敞开所有关上的表，并产生FTWRL锁 ，而后疾速开释FTWRL锁。general_log 日志显示如下： FLUSH /*!40101 LOCAL */ TABLESFLUSH TABLES WITH READ LOCKSET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READSTART TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */如果这时候以后的数据库曾经有表锁，那么dump操作会被梗塞,直到先前的表锁被开释后继续执行；或者超过锁定工夫 lock_wait_timeout 后退出。 上面是先模仿执行了 LOCK TABLES t_user READ; 操作后，dump操作被梗塞的状况。 (Sun Nov 21 06:42:07 2021)[root@GreatSQL][(none)]>show processlist;+----+-----------------+-----------+------+---------+-------+-------------------------+--------------------------------+----------+-----------+---------------+| Id | User | Host | db | Command | Time | State | Info | Time_ms | Rows_sent | Rows_examined |+----+-----------------+-----------+------+---------+-------+-------------------------+--------------------------------+----------+-----------+---------------+| 5 | event_scheduler | localhost | NULL | Daemon | 77523 | Waiting on empty queue | NULL | 77523235 | 0 | 0 || 11 | root | localhost | test | Sleep | 266 | | NULL | 266664 | 0 | 0 || 14 | root | localhost | NULL | Query | 263 | Waiting for table flush | FLUSH /*!40101 LOCAL */ TABLES | 263751 | 0 | 0 || 17 | root | localhost | NULL | Query | 0 | init | show processlist | 0 | 0 | 0 |+----+-----------------+-----------+------+---------+-------+-------------------------+--------------------------------+----------+-----------+---------------+4 rows in set (0.00 sec)--master_data=1|2 参数阐明： ...

在Ubuntu下编译装置GreatSQL本次介绍如何利用Docker构建Ubuntu环境，并将GreatSQL源码编译成二进制文件。 1、筹备工作先创立本次Docker的workdir为 /data/docker-ubuntu： [root@greatsql ~]# mdkir /data/docker-ubuntu1.1、配置Ubuntu环境下的apt源配置文件开始编译之前，倡议先配置好apt源，这样后续部署环境下载软件包时速度更快。 以阿里、腾讯两大云主机为例，能够这样配置（两个apt源自行二选一）： #腾讯云[root@greatsql ~]# cat /data/docker-ubuntu/ubuntu-20.4-sources.listdeb http://mirrors.cloud.tencent.com/ubuntu/ focal main restricteddeb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates main restricteddeb http://mirrors.cloud.tencent.com/ubuntu/ focal universedeb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates universedeb http://mirrors.cloud.tencent.com/ubuntu/ focal multiversedeb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates multiversedeb http://mirrors.cloud.tencent.com/ubuntu/ focal-backports main restricted universe multiversedeb http://mirrors.cloud.tencent.com/ubuntu/ focal-security main restricteddeb http://mirrors.cloud.tencent.com/ubuntu/ focal-security universedeb http://mirrors.cloud.tencent.com/ubuntu/ focal-security multiverse如果是阿里云的话换成上面的内容 deb http://mirrors.aliyun.com/ubuntu/ focal main restricteddeb http://mirrors.aliyun.com/ubuntu/ focal-updates main restricteddeb http://mirrors.aliyun.com/ubuntu/ focal universedeb http://mirrors.aliyun.com/ubuntu/ focal-updates universedeb http://mirrors.aliyun.com/ubuntu/ focal multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-updates multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu/ focal-security main restricteddeb http://mirrors.aliyun.com/ubuntu/ focal-security universedeb http://mirrors.aliyun.com/ubuntu/ focal-security multiverse这个文件先筹备好，前面会在Dockerfile里用到它。 ...

I、锁分类锁加锁开释锁全局锁Flush tables with read lock(FTWRL)unlock tables表锁lock tables ... read/writeunlock tables行锁事务更新记录时事务COMMIT之后锁粒度越大，开销越小，锁抵触的概率越小，安全性也就越高，但业务并发度以及性能越差；反之锁粒度越小，开销也就越大，锁抵触的概率越大（易导致死锁），安全性也就越低，但业务并发度以及性能越好。II、全局锁1、应用场景：全库逻辑备份。反对MVCC的可不必。2、应用危险：——如果在主库备份，在备份期间不能更新，业务停摆——如果在从库备份，备份期间不能执行主库同步的binlog，导致主从提早。3、官网自带的逻辑备份工具mysqldump，当mysqldump应用参数--single-transaction的时候，会启动一个事务，确保拿到一致性视图。而因为MVCC的反对，这个过程中数据是能够失常更新的。然而前提是引擎要反对这个隔离级别。4、如果要全库只读，为什么不应用set global readonly=true的形式？——在有些零碎中，readonly的值会被用来做其余逻辑，比方判断主备库。所以批改global变量的形式影响太大。——在异样解决机制上有差别。如果执行FTWRL命令之后因为客户端产生异样断开，那么MySQL会主动开释这个全局锁，整个库回到能够失常更新的状态。而将整个库设置为readonly之后，如果客户端产生异样，则数据库就会始终放弃readonly状态，这样会导致整个库长时间处于不可写状态，危险较高。 III、表级锁1、分类：表锁，元数据所(meta data lock,MDL)。表锁的语法是:lock tables ... read/write2、unlock tables命令被动开释锁，客户端断开的时主动开释。3、lock tables语法除了会限度别的线程的读写外，也限定了本线程接下来的操作对象。对于InnoDB这种反对行锁的引擎，个别不应用lock tables命令来管制并发，毕竟锁住整个表的影响面还是太大。4、MDL保障读写的正确性——不须要显式应用，在拜访一个表的时候会被主动加上。——何时应用：在对一个表做增删改查操作的时候；当要对表做构造变更操作的时候——读锁之间不互斥。读写锁之间，写锁之间互斥。——MDL直到事务提交才开释 IV、行锁1、两阶段锁协定：在 InnoDB 事务中，行锁是在须要的时候才加上的，但并不是不须要了就立即开释，而是要等到事务完结时才开释。2、如果你的事务中须要锁多个行，要把最可能造成锁抵触、最可能影响并发度的锁尽量往后放。锁的粒度越大，锁抵触的可能性越大，语句越后执行；锁粒度越小，锁抵触的可能性越小，语句越先执行。3、死锁：当并发零碎中不同线程呈现循环资源依赖，波及的线程都在期待别的线程开释资源时，就会导致这几个线程都进入有限期待的状态。如A等B，B等C，C等A。4、死锁解决方案：——设置超时工夫（参数：innodb_lock_wait_timeout，InnoDB默认50s）。——发动死锁检测。发现死锁后，被动回滚死锁链条中的某一个事务，让其余事务得以持续执行（参数：innodb_deadlock_detect=on，默认开启）。过程示例：新来的线程F，被锁了后就要查看锁住F的线程（假如为D）是否被锁，如果没有被锁，则没有死锁，如果被锁了，还要查看锁住线程D的是谁，如果是F，那么必定死锁了，如果不是F（假如为B），那么就要持续判断锁住线程B的是谁，始终走晓得发现线程没有被锁（无死锁）或者被F锁住（死锁）才会终止。5、热点行更新景象：每个新来的被堵住的线程，都要判断会不会因为本人的退出导致了死锁，这是一个工夫复杂度是O(n)的操作。假如有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。尽管最终检测的后果是没有死锁，然而这期间要耗费大量的CPU资源。热点行更新：1、不倡议：如果你能确保这个业务肯定不会呈现死锁，能够长期把死锁检测敞开掉。2、管制并发度。对应雷同行的更新，在进入引擎之前排队。这样在InnoDB外部就不会有大量的死锁检测工作了。如果你有中间件，能够思考在中间件实现；如果你的团队有能批改 MySQL 源码的人，也能够做在 MySQL 外面。基本思路就是，对于雷同行的更新，在进入引擎之前排队。这样在 InnoDB 外部就不会有大量的死锁检测工作了。3、将热更新的行数据拆分成逻辑上的多行来缩小锁抵触，然而业务复杂度可能会大大提高。

试验五:触发器与存储过程(函数)1. 针对SPJ_MNG数据库，创立并执行如下存储过程。（共计40分）(1) 创立一个没有参数的存储过程—jsearch1。该存储过程的作用是：当执行该存储过程时，将返回S表中北京供应商的所有信息。调用该存储过程并验证后果。（5分）delimiter $$create procedure jsearch1()begin select * from s where city = '北京';end$$delimiter ; (2) 创立带输出参数的存储过程—jsearch2。该存储过程的作用是：当输出一个供应商所在城市名时（如北京），将返回该供应商的所有信息。调用存储过程并验证后果。（5分）delimiter $$create procedure jsearch2(in in_city varchar(45))begin select * from s where city = in_city;end$$delimiter ; (3) 创立带输出参数和输入参数的存储过程(函数)—jsearch3。该存储过程的作用是：当输出一个供应商编号(输出参数SNO)时，将返回该供应商的名称(输入参数SNAME)。调用存储过程并验证后果。（5分）delimiter $$create procedure jsearch3 (in in_sno varchar(45), out out_sname varchar(45))begin select sname from s where sno = in_sno;end$$delimiter ; (4) 创立一个应用游标的存储过程jsearch4，创立胜利后调用该存储过程并验证后果。该存储过程的性能：当输出一个工程号JNO时，将返回供应该工程整机的所有供应商的名称(SNAME)，这些供应商名拼接成一个字符串，并用逗号’,’分隔。例如： 输出：J2，输入： '精益, 盛锡, 为民'。（10分） delimiter $$create procedure jsearch4(in in_jno varchar(45))begin #定义变量 declare result varchar(100) default ''; declare tmp_name varchar(100); declare done int default 0; #创立游标 declare cur_sname cursor for select distinct sname from s,spj where in_jno = spj.jno and spj.sno = s.sno; #生成后果 declare continue handler for sqlstate '02000' set done = 1; open cur_sname; fetch cur_sname into tmp_name; repeat set result = concat(result, tmp_name); set result = concat(result, ', '); fetch cur_sname into tmp_name; until done end repeat; close cur_sname; select left(result, char_length(result)-2); end$$delimiter ; ...

接手的新我的项目，接踵而至的呈现账不平的问题，作为程序员中比拟执着的人，不解决誓不罢休。最终，通过两次，历时多日终于将其连根拔起。实属不易，特写篇文章记录一下。 文章中不仅会讲到应用乐观锁踩到的坑，以及自己是如何排查问题的，某些思路和办法或者能对大家有所帮忙。 事件的起源经营共事时不时就提出查账调账的需要，起因很简略，账不平，不查不行。如果你有过财务相干零碎的工作经验，账务问题始终是最难攻克的。 尽管刚接手我的项目，尽管很多业务逻辑还不理解，但呈现这样的技术挑战，还是要坚定攻克的。 其实，这类问题的起因很简略：热点账户。当很多服务或线程操作同一个用户的账户时，就会呈现一个更新把另外一个更新笼罩掉的状况。 上图可轻易看出，当两个服务或线程同时查询数据库的一条数据（热点账户），而后内存中做批改，最初更新到数据库。如果呈现并发状况，两个线程都读取了100，一个计算得80，一个计算得60，后更新的就有可能将后面的笼罩掉。 解决方案通常有： 单服务线程锁；集群分布式锁；集群数据库乐观锁；我的项目中已采纳了乐观锁，就基于来进行排查追踪起因。 何谓乐观锁乐观锁是在对数据被的批改持乐观态度，在整个数据处理过程中会将数据锁定。 乐观锁的实现，往往依附数据库提供的锁机制（也只有数据库层提供的锁机制能力真正保证数据拜访的排他性，否则，即便在应用层中实现了加锁机制，也无奈保障内部零碎不会批改数据）。 通常会应用select ... for update语句来实现对数据的桎梏。 for update仅实用于InnoDB，且必须在事务块(BEGIN/COMMIT)中能力失效。在进行事务操作时，通过“for update”语句，MySQL会对查问后果集中每行数据都增加排他锁，其余线程对该记录的更新与删除操作都会阻塞。排他锁蕴含行锁、表锁。 如下示例展现了乐观锁的根本应用流程： set autocommit=0;　//设置完autocommit后，执行失常业务。具体如下：//0.开始事务begin;/begin work;/start transaction; (三者选一就能够)//1.查问出商品信息select status from t_goods where id=1 for update;//2.依据商品信息生成订单insert into t_orders (id,goods_id) values (null,1);//3.批改商品status为2update t_goods set status=2;//4.提交事务commit;/commit work;因为敞开了数据库主动提交，这里通过begin/commit来治理事务。 应用select…for update的形式通过数据库实现了乐观锁。其中，id为1的那条数据就被锁定，其它的事务必须等本次事务提交之后能力执行。这样就保障了在操作期间数据不会被其它事务批改。 起因初步剖析在理解了账不平的起因和乐观锁的基本原理之后，就能够进行问题的排查了。既然零碎曾经应用了乐观锁，居然还会呈现问题，那必定是哪里漏掉了什么。 于是，排查了所有账户（account表）更新的中央，还真找到一处bug。 大多数中央都应用了乐观锁，先for update查问一下，而后计算新的余额，再进行更新数据库。但有一处居然先查问到了计算了余额，而后再进行加锁，最初更新。 根本流程如下： 在上述情况中，尽管线程B进行了加锁解决，但因为计算新余额并未在锁中，导致尽管应用了乐观锁，但仍旧存在问题。正确的应用形式就是将计算余额的逻辑放在锁中。 当然，如果线程B齐全被忘记加锁了，也会呈现同样的问题。 在排查解决了上述bug，我开始嘚瑟了，认为彻底解决了账不平的问题。 一个月之后后果一个月之后，经营共事又来找了，偶然依旧会呈现账不平的问题。刚开始我还认为是不是搞错了，历史的账不平导致当初最终的不平。但最终还是下定决心再排查一次。 第一天，把账不平的账户的账务流水、波及到代码、日志全副捋一遍。这期间还遇到了很多小艰难，最终留神克服。 艰难一：数据查不动账务记录表数据太多，上千万的数据，最后的设计者并没有创立索引。这就要了老命了，依据筛选条件基本查不出数据来。 这里就用到SQL优化的两个技能点：limit限度查问条数和高效的分页策略。 对于limit限度查问条件这一点很显著，不仅缩小了后果集，而且在遇到符合条件的数据之后会立马返回。 高效的分页策略在列表页在查问数据常常遇到，为了防止一次性返回过多的数据影响接口性能，个别会对查问接口做分页解决。 在Mysql中分页个别用的limit关键字： select id,name,age from user limit 10,20;大量数据时，limit分页没啥问题。但如果表中数据量很多，就会呈现性能问题。 比方分页参数变成了： select id,name,age from user limit 1000000,20;Mysql会查到1000020条数据，而后抛弃后面的1000000条，只查前面的20条数据，十分浪费资源。 ...

如果你打算从近程连贯 MySQL 服务器的话，有可能会碰到 10061 谬误，这个谬误特地常见，通常的谬误提醒是「Driver Error, Can’t connect to MySQL server on ‘YOUR_IP_ADDRESS’ (10061)」 导致 10061 这个谬误的状况有两种 登录账号近程拜访权限问题MySQL 配置文件设置问题本教程将具体解说，如何针对这两种状况进行配置，以修改 10061 谬误。 特地提醒：对于如何关上 MySQL 近程拜访性能，可看这篇《如何近程连贯 MySQL 数据库，阿里云腾讯云外网连贯教程》，如果想开启服务器可查看这份教程，本篇教程只讲开启后，为什么会呈现 10061 谬误。另外举荐一下卡拉云，只有你能写 SQL ，不会任何前端也能够用卡拉云疾速搭建属于本人的后盾管理系统，详见本文文末 一. 受权登录 MySQL 服务器的账号近程拜访权限如果账号没有近程拜访权限或 host 配置谬误，会导致 10061 谬误。咱们能够新建一个账号用于近程登录，也能够批改已有账号的 host 配置，使它能够近程拜访。 1. 新建用于近程登录的 MySQL 账号MySQL 用户账号是否能够近程登录，取决于账号中的 host 配置。host 指定该账号在哪些主机上能够登录，如果是本地用户可用 localhost，如果是近程用户，须要指定近程计算机的 IP，如果想任意主机均可登录，那么能够应用通配符 % 本教程应用通配符 % 来作为账号 host 的设置，你能够依据本人的状况将 % 改为指定主机 IP，这样能够是 MySQL 近程登录更加平安。 首先登录 MySQL Server mysql -u root -p而后新建一个用于近程登录的 MySQL 账号，这里的「password」换成你的明码，如果MySQL 设置为严格明码的话，须要「数字+英文大小写+符号」 CREATE USER 'kalacloud.com-remote'@'%' IDENTIFIED WITH mysql_native_password BY 'password';接着，依据本人的须要，给你用于近程拜访的账号赋予权限。上面的例子是给账号全局权限，包含创立（CREATE）、批改（ALTER）、删除（DROP） 数据库、表、用户，任意表的插入（INSERT）、更新（UPDATE）、删除（DELETE）操作权限。能够应用 SELECT 查问数据，应用 REFERENCES 建设外键关系权限，以及应用 RELOAD 权限执行 FLUSH 操作的权限。 ...

1. 前言近日，微步在线旗下微步情报局利用收费社区蜜罐 HFish 捕捉到 GitLab 未受权近程命令执行破绽（CVE-2021-22205）在朝利用，攻打胜利后攻击者会植入挖矿木马进行挖矿。该破绽无需进行身份验证即可进利用，危害极大。GitLab 是 GitLab Inc. 开发用于代码仓库管理系统的开源我的项目。因为 GitLab 广泛应用于多个企业，该破绽影响范畴较广。公众号后盾回复“GL”获取相干IOC。 2. 事件详情在2021年“双11”前夜，HFish 蜜罐与 OneEDR 联合行动，捕捉并处理了一起实在利用 GitLab 未受权近程命令执行破绽（CVE-2021-22205）在朝破绽进行挖矿的攻打。依据部署在互联网的 GitLab 服务模仿蜜罐显示，该攻打第一次产生在11月10日早晨21点，某国内 IP 通过简略扫描踩点后，发送可疑 HTTP POST 申请，通过剖析确认该破绽为利用 ExifTool 解析图片异样导致命令执行的 CVE-2021-22205。11月11日捕捉到了样本并提取行为特色推送给 OneEDR 客户。因为该破绽利用简略，且利用代码曾经公开，多个企业用户曾经感知局部主机失陷，主机告警界面呈现了多条告警信息，告警名称是木马过程 xmrig，钻研人员依据文件的名称断定是与挖矿相干的木马。 3. 告警排查剖析点击日志详情，在2021/11/11 18:10 - 2021/11/11 18:20 工夫内，发现有多个文件下载行为。点击其中一个日志查看详情能够发现，该操作第一次产生是在 GitLab 相干的目录，初步狐疑是通过 GitLab 破绽进来的。登录服务器排查，查看 GitLab 的相干日志，发现有同一可疑 IP 屡次拜访 GitLab，post 申请传输数据的工夫与 OneEDR 产生告警工夫简直统一。 cat production.log | grep POST钻研人员利用 CVE-2021-22205 破绽的 exp 去验证该 GitLab 是不是存在 GitLab rce (CVE-2021-22205)的破绽，通过验证发现确认，该 GitLab 存在 RCE 破绽。接着，把 xmrig 木马拿到本地虚拟机进行剖析，发现该木马是门罗币挖矿木马，它能够指定 url 进行挖矿、后盾运行挖矿程序、以及指定钱包地址等形式进行挖矿流动 。 ...

景象与问题ORDER BY排序后，用LIMIT取前几条，发现返回的后果集的程序与预期的不一样。上面是我遇到的问题： 能够看到，带LIMIT与不带LIMIT的后果与我预期的不一样，而且“很不堪设想”，真是百思不得其解。 起初百度了一下，如果order by的列有雷同的值时，mysql会随机选取这些行，为了保障每次都返回的程序统一能够额定减少一个排序字段（比方：id），用两个字段来尽可能减少反复的概率。 于是，改成 order by status, id; 问题尽管是解决了，但还是看看官网文档上怎么说的吧！ LIMIT查问优化摘自“LIMIT查问优化”如果你只须要后果集中的指定数量的行，那么请在查问中应用LIMIT子句，而不是抓取整个后果集并抛弃剩下那些你不要的数据。 MySQL有时会优化一个蕴含LIMIT子句并且没有HAVING子句的查问： MySQL通常更违心执行全表扫描，然而如果你用LIMIT只查问几行记录的话，MySQL在某些状况下可能会应用索引。如果你将LIMIT row_count子句与ORDER BY子句组合在一起应用的话，MySQL会在找到排序后果的第一个row_count行后立刻进行排序，而不是对整个后果进行排序。如果应用索引来实现排序，这将十分快。如果必须执行文件排序，则在找到第一个row_count行之前，抉择所有与查问匹配但不包含LIMIT子句的行，并对其中大部分或所有行进行排序。一旦找到第一个row_count之后，MySQL不会对后果集的任何残余局部进行排序。这种行为的一种表现形式是，一个ORDER BY查问带或者不带LIMIT可能返回行的程序是不一样的。如果LIMIT row_count与DISTINCT一起应用，一旦找到row_count惟一的行，MySQL就会进行。LIMIT 0 能够疾速返回一个空的后果集，这是用来检测一个查问是否无效的一种很有用的办法。如果服务器应用长期表来解析查问，它将应用LIMIT row_count子句来计算须要多少空间。如果ORDER BY不走索引，而且前面还带了LIMIT的话，那么优化器可能能够防止用一个合并文件，并应用内存中的filesort操作对内存中的行进行排序。如果ORDER BY列有多行具备雷同的值，服务器能够自在地以任何程序返回这些行，并且依据总体执行打算可能以不同的形式返回。换句话说，这些行的排序程序对于无序列是不确定的。 影响执行打算的一个因素是LIMIT，因而对于一个ORDER BY查问而言，带与不带LIMIT返回的行的程序可能是不一样的。 看上面的例子： 蕴含LIMIT可能会影响每一个category行的程序。例如： 如果你须要确保无论带不带LIMIT都要以雷同的程序返回，那么你能够在ORDER BY中蕴含附加列，以使程序具备确定性。例如： 小结1、如果你只须要后果集中的某几行，那么倡议应用limit。这样这样的话能够防止抓取全副后果集，而后再抛弃那些你不要的行。2、对于order by查问，带或者不带limit可能返回行的程序是不一样的。 3、如果limit row_count 与 order by 一起应用，那么在找到第一个row_count就进行排序，间接返回。 4、如果order by列有雷同的值，那么MySQL能够自在地以任何程序返回这些行。换言之，只有order by列的值不反复，就能够保障返回的程序。 5、能够在order by子句中蕴含附加列，以使程序具备确定性。 https://cloud.tencent.com/dev...

1、问题形容前两天在群里看到共事反馈一个空格问题，大抵景象如下： mysql> select @@version;+-----------+| @@version |+-----------+| 8.0.25 |+-----------+1 row in set (0.00 sec)mysql> create table t1( -> c1 int, -> c2 varchar(4) check(c2<>'') #单引号之间无空格 -> )engine=innodb;Query OK, 0 rows affected (0.21 sec)mysql> insert into t1 select 1,' '; #c2字段插入两个空格ERROR 3819 (HY000): Check constraint 't1_chk_1' is violated.check定义c2<>''，往c2字段插入空格，提醒违反check束缚。 为什么insert语句中的' '(单引号之间有一个或多个空格)会被判断为''(单引号之间无空格)，导致插入失败？ 2、波及常识2.1、Stored and Retrievedhttps://dev.mysql.com/doc/refman/8.0/en/char.html When CHAR values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed unless the PAD_CHAR_TO_FULL_LENGTH SQL mode is enabled. ...

从零开始学mysql - 零碎参数和配置前言 本节咱们来讲述对于MYSQL的系统启动命令相干内容，也是比拟根底然而可能有些人会很含糊的内容，本节的外围也是讲述配置无关的内容 思维导图导图地址：https://www.mubucm.com/doc/7D... 概述 上面是对于本文的简略提要： ，命令行的命令格局 单划线和双划线配置文件 配置文件读取程序 window，mac，Linux的配置读取程序比照配置文件的内容特定版本配置配置文件优先级 多配置文件和单文件配置的读书个性：总是以最初为准自定义配置读取：通常为命令行指定读取零碎变量的配置 查看零碎变量设置零碎变量运行时的零碎变量 作用范畴：全局变量和会话变量全局变量和会话变量设置查看零碎变量的范畴零碎变量的注意事项启动选项和零碎变量的区别状态变量的补充 如何查看状态变量命令行命格局单划线和双划线命令格局 命令行命令就是咱们通常连贯mysql应用的命令，命令行的命令个别分为两种，首先是双划线的命令，比方应用mysqld --skip-networing 就能够禁止客户端连贯，这种命令也被称之为长命令，应用命令的时候须要应用--两个短划线进行拼接，另一种是更为罕用的命令-h，-p等命令， 这样的命令只须要一个短划线即可（为--host，--port的命令简称）。 命令的另一种写法是应用下划线进行代替，--skip_networing。 单划线命令成果如下，服务端开启禁止客户端登陆之后应用客户端连贯就不容许了： mysql -h127.0.0.1 -uroot -p Enter password:ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (61) 另外一个案例是服务端启动的默认创立表引擎，比方咱们须要改为InnoDB引擎在应用命令的时候加上--default-storage-engine=InnoDB选项，最初只有在任意的数据库下创立一张表，在开端能够发现表的的存储引擎变了，当然默认的存储引擎看不到成果，能够应用MyISAM进行验证： ENGINE=MyISAM DEFAULT CHARSET=utf8 mysql的默认装置之后启动会主动附加一些参数，比方上面的命令，这里有个命令的重要应用规定是不要把变量申明的习惯带进来，在命令的=（等号）两边减少空格是不被容许的： /usr/local/mysql/bin/mysqld --user=_mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --log-error=/usr/local/mysql/data/mysqld.local.err --pid-file=/usr/local/mysql/data/mysqld.local.pid --keyring-file-data=/usr/local/mysql/keyring/keyring --early-plugin-load=keyring_file=keyring_file.so 最初如果不分明如何应用命令，间接应用--help，不过只有一个mysqld的比拟非凡，他须要应用--verbose --help才行，记不住也没关系，在--help的命令最初mysql会给咱们进行提醒，还是比拟贴心的（不过我感觉大多数人还是会应用度娘查命令，哈哈。） For more help options (several pages), use mysqld --verbose --help.配置文件 尽管命令的形式非常的不便，在启动的时候也有较高的自由度，然而这种形式用的其实并不是很多，理论工作应用配置文件的模式会更多，配件文件的模式是更为罕用的也是更容易记忆的形式，然而在理解配置文件之前，咱们须要大抵理解配置文件的读取程序。当然不须要牢固的记忆，只有作为理解即可。 配置文件的读取程序Window的配置文件读取程序 Windows不是应用MySQL的重点，然而作为自我练习的时候还是须要理解的，他的配置读取程序如下。 %WINDIR%\my.ini %windir\my.cnf% （echo %WINDIR%获取）C:\my.ini C:\my.cnfBasdir\my.ini basdir\my.cnf（based it指的是默认的装置门路）Defaults-extra-file 命令行制订的额定配置文件门路%appdata%\MySQL\ .mylogin.cnf 登陆门路选项（客户端指定，通过echo %APPDATA%能够获取） 下面第一条呈现.ini和.cnf意味着反对多种后缀文件格式，%windir% 示意为windows的目录地位，通常是C:\windows。另外最初两个配置有点特地，第四个指的是能够利用命令参数：—defaults-extra-file=C:\xxxx\xxx\xxx.txt这样的形式指定要读取的配置文件，而最初一个%appdata%指的是windows对应应用程序目录值，另外这个.mylogin.cnf（留神后面的小数点） 这个文件不是和后面一样相似的纯文本，而是应用mysql_config_editor 应用程序的加密文件，文件也只能固定为mysql规定的一些配置信息。（这些配置这里借用官网查看一下） ...

阿里云官网镜像站：OceanBase、MySQL镜像源 https://developer.aliyun.com/... 概述OceanBase是阿里巴巴和蚂蚁金服齐全自主研发的通用的分布式关系型数据库，定位为商用企业级数据库。OceanBase能提供金融级别的可靠性，目前次要利用用于金融行业，同时也实用于非金融行业场景。它交融传统关系数据库和分布式系统的劣势，利用一般的PC服务器组成数据库集群，领有杰出的线性扩展性。 通过在底层分布式引擎实现的Paxos多数派协定和多正本个性，OceanBase领有了令人称道的高可用和容灾能力，不负“永不停机”的数据库系统的盛名，能够完满反对多地多活、异地容灾等高可用部署。 OceanBase是一个准内存数据库系统，独有的读写拆散架构和面向SSD固态盘的高效存储引擎，为用户带来了超高性能的体验。 OceanBase定位为云数据库，通过在数据库外部实现多租户隔离，实现一个集群能够服 务多个租户，且租户之间齐全隔离，不会相互影响。 OceanBase目前齐全兼容MySQL，用户能够零老本从 MySQL 迁徙到OceanBase。同时OceanBase在数据库外部实现了分区表和二级分区性能，能够齐全取代MySQL罕用的分库分表计划。 OceanBase的存储引擎OceanBase实质上是一个基线加增量的存储引擎，跟关系数据库差异很大。 存储机制是LSM树，这也是大多数NoSQL应用的存储机制。OceanBase采纳了一种读写拆散的架构，把数据分为基线数据和增量数据，其中增量数据放在内存里（MemTable），基线数据放在SSD盘（SSTable）。尽管不是刻意设计的，但OceanBase的确比传统数据库更适宜像双十一、秒杀以及优惠券销售等短时间突发大流量的场景： 短时间内大量用户涌入，短时间内业务流量十分大，数据库系统压力十分大一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或显著回落OceanBase是“基线数据（硬盘）”+“批改增量（内存）”的架构，如下图所示。 整个数据库以硬盘（通常是SSD）为载体，对数据的批改都是增量数据，只写内存，早先的增、删、改数据（批改增量）在内存，所以DML是齐全的内存操作，性能十分高。而基线数据在保留在硬盘上，因而OceanBase能够看成一个准内存数据库。这样做的益处有： 写事务在内存（除事务日志必须落盘外），性能大大晋升。没有随机写硬盘，硬盘随机读不受烦扰，高峰期零碎性能晋升显著；对于传统数据库，业务高峰期通常也是大量随机写盘（刷脏页）的高峰期，大量随机写盘耗费了大量的IO，特地是思考到SSD的写入放大，对于读写性能都有较大的影响。基线数据只读，缓存（cache）简略且成果晋升。读数据的时候，数据可能会在内存里有更新过的版本，在长久化存储里有基线版本，须要把两个版本进行合并，取得一个最新版本。同时在内存实现了Block Cache和Row cache，来防止对基线数据的随机读。当内存的增量数据达到肯定规模的时候，会触发增量数据和基线数据的合并，把增量数据落盘（称为转储，又叫minor freeze）。同时每天晚上的闲暇时刻，零碎也会主动每日合并(简称合并，major freeze)。 OB为何采纳这种非凡架构，简要来说，就是基于这样一条实践根底——只管数据库自身的数据量越来越大，记录数越来越多，但每天的增删改数据量并不大，仅仅只占数据库总量一个很小的比例。 这个状况不只是对支付宝的领取数据，对其它大部分数据库理论利用状况也实用，是OB建设上述存储引擎的重要实践根底。 每日合并，必然波及到大量的硬盘读写（IO），因而可能对业务的吞吐量和事务响应工夫（RT）产生影响。如何防止每日合并对业务的影响呢？OceanBase通过“轮转合并”解决了这个问题。 家喻户晓，出于高可用的思考，OceanBase是三机群部署。 依据配置和部署的不同，业务顶峰时能够一个机群、两个机群或者三个机群提供读写服务。OceanBase的轮转合并就是对每个机群轮转地进行每日合并，在对一个机群进行每日合并之前，先把该机群上的业务读写流量切换到另外的一个或两个机群，而后对该机群进行全速的每日合并。 因而在每日合并期间，合并进行中的机群没有业务流量，仅仅接管事务日志并且参加Paxos投票，业务拜访OceanBase的事务响应工夫齐全不受每日合并的影响，仅仅是OceanBase的总吞吐量有所降落：如果先前是三个机群都提供服务则总吞吐量降落1/3，如果先前只有一个或两个机群提供服务则总吞吐量没有变动。 轮转合并使得OceanBase对SSD非常敌对，防止了大量随机写盘对SSD寿命的影响，因而OceanBase能够应用绝对便宜的“读密集型”SSD来代替传统数据库应用的绝对低廉的“读写型”SSD，而不影响性能。此外因为轮转合并对服务器的CPU应用、硬盘IO应用以及耗时长短都不敏感（高峰期的传统数据库在刷脏页的同时还要优先保障业务拜访的吞吐量和事务响应工夫，刷脏页的CPU及IO资源都十分受限），因而OceanBase在每日合并时能够采纳更加高效的压缩或者编码算法（比方压缩或编码速度略慢，但压缩率较高、解压缩很快的算法），从而进一步升高存储老本并晋升性能。 每日合并提供了很多益处，但也须要接受肯定的代价；整体上来说，每日合并会是一个比拟费时的操作，对系统的 IO 和 CPU 会有比拟多的耗费。为了使每日合并应用系统资源对系统带来的影响尽可能的升高，比拟常见的做法是将每日合并的操作放在业务的低峰期间（如夜间时刻）进行。 OceanBase如何保障写的原子性分布式数据库技术具体难在哪里呢？简略说，要想账头一分钱都不错，数据库要反对事务，事务领有ACID准则，这四个字母别离代表：A原子性、C一致性、I隔离性、D持久性。 原子性：示意事务中的多个操作要么全副实现，要么全副失败，不会呈现中间状态，例如A转给B100块钱，A账户扣除100块的同时，B账户必须减少100块钱。这两件事必须像一个原子一样紧紧抱在一起，决不允许“A曾经扣钱，B还没加钱”的事件产生。一致性：A转给B100块钱，转账实现的一瞬间，A霎时再查问本人的最新余额，必须显示曾经扣除100之后的金额，B必须霎时查到曾经加上100块之后的余额。所有的账目在任何一个工夫切面必须完完全全对得上。隔离性：示意多个并发事务之间不相互影响，A转给B100块钱，不能对C有任何影响。持久性：示意事务一旦胜利就不会失落，A转给B100块钱，这笔转账一旦实现，就永远失效。其中一致性是目标，原子性隔离性和长久化是伎俩，只有做好ACID中的AID，C天然就能满足。 因为数据散落在多台数据库服务器上，库作了拆分。分布式写最大的难度其实就在于保障ACID中的那个A——原子性。 举个例子，假如A给B转100块钱，因为是“分布式数据库”，A用户的账户数据存在A机器上，B用户的账户数据存在B机器上。 如果交易产生时，负责给A账户扣100块钱的A机器死机,没有扣胜利，而负责给账户B加100块钱的B机器工作失常，加上了100——这就会造成支付宝损失100块。 反之，如果负责给A账户扣100块钱的A机器失常，曾经扣掉100，而负责给账户B加100块钱的B机器死机，100块没加上，那么用户就会损失100——最初支付宝还要抵偿用户100块。 为了保障以上这两种难堪的场面不产生，OceanBase 1.0 采纳了整整一组技术，但最次要的是两个。 投票机制数据库采纳“三正本”，也就是任何一个账户，都有一个主咖两个备胎共三份雷同的数据。 举例来说：账户A的数据肯定同时存在三台机器上。转账时，至多两台机器执行结束才算转账实现，这意味着，三台机器里有一台坏掉，并不影响转账的执行。同时，三台机器之间互相实时发送“心跳信号”，如果有一台机器挂了，其余两台马上就能感觉到，解决完手头这个交易后，马上向零碎发送警报，零碎主动为他俩匹配一个新搭档，三台机器持续工作。而换下来那个坏机器，交给技术人员培修，修好后从新上架成为备用机器，期待进入战斗序列。 也就是说，除非两台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。 即便是这还不够，在要害的节点，OceanBase 会采纳五个节点投票。也就是除非三台机器在同年同月同日同分同秒同毫秒坏掉，否则数据库的工作不受影响。这个概率曾经低到尘土里了。 oceanBase在存储层，通过分区级Paxos日志同步实现高可用和主动扩大，反对灵便的存储架构，包含本地存储，以及存储计算拆散。经典集中式数据库往往采纳主备同步计划，有两种同步模式：第一种是强同步，每个事务操作都须要强同步到备机才能够应答用户，这种形式可能做到服务器故障不丢数据，但必须停服务，无奈保障可用性；另外一种是异步，每个事务操作只须要在主机胜利就能够应答用户，这种形式可能做到高可用，但主库和备库之间数据不统一，备库切换为主库之后会丢数据。 强统一和高可用作为数据库最重要的两个个性，在主备同步模式下，鱼和熊掌不可兼得。Paxos是一种基于多数派的分布式投票协定，每个事务须要胜利写入超过一半服务器才能够应答用户。俗话说得好，“三个臭皮匠顶过一个诸葛亮”，假如总共有3台服务器，每个事务操作要求至多在2台服务器上胜利，无论任何一台服务器产生故障，零碎中还有1台蕴含了全副数据的服务器可能失常工作，从而做到齐全不丢数据，并在30秒之内选出新的主库复原服务，RPO等于0，RTO小于 30秒。所有保障RPO=0的协定都是Paxos协定或者Paxos协定的变种，Raft协定就是其中之一。 监督机制监督机制其实是对两阶段提交协定（2PC）的实际，认真想想，除了机器坏掉，还有一些状况会毁坏交易的原子性。 例如：A账户要扣掉100块，然而它的余额只有90块，或者曾经达到了明天的转账限额，这种状况下，如果贸然给B账户加了100块，A账户却不够扣，就会陷入麻烦了。 反之如果B账户状态有异样，不能加100块，同样会有麻烦。解决这个问题的办法，就是引入一位“裁判员”。裁判员站在A账户和B账户旁边，它的工作流程是这样的： 裁判员问A账户：你的三台机器都没问题吧？A账户说：没问题。裁判员问A账户：你的账户容许扣100吗？A账户说：容许。裁判员问B账户：你的三台机器都没问题吧？B账户说：没问题。裁判员问B账户：你的账户状态能承受加100吗？B说：容许。这时，裁判员吹哨，A、B账户同时解冻。A扣100，B加100，单方向裁判汇报“胜利”。裁判员再吹哨，A、B账户同时冻结。以上7步，都是按工夫程序实现的，卡在任何一步，账目都不会乱，一分钱都不会丢。完全符合“原子化”的要求。 裁判员充当2PC中的协调器角色。 OceanBase如何保障事务的隔离性数据库系统不能只服务一个用户，须要容许多个用户同时操作数据，即并发。所以须要保障多个并发事务的隔离，这里波及到并发控制技术，常见的并发管制办法有基于锁的并发管制（Lock based Concurrency Controll）和多版本并发管制（Multiple version Concurrency Controll） 基于锁的并发管制数据库系统对用户在事务过程中操作的每一行数据都加锁，读操作加读锁，写操作加写锁。读写阻塞，写写阻塞。如果两个不同的事务试图批改同一行数据，事务1先加上写锁失常执行，事务2就只能阻塞期待，当事务1执行完结开释写锁后，事务2再继续执行。 以转账操作为例，A账户有100元，B账户有200元，如果事务1执行从A账户转10元到B账户，那么在事务1执行过程中，A B两行账户数据都会被加上写锁。如果事务2执行另一次转账操作，从A账户转50元到B账户，那么给A加写锁时失败，事务2会始终期待直到加写锁胜利为止。 ...

背景前段时间遇到一个线上问题，起初排查良久发现是因为主从同步提早导致的，所以明天写一篇文章总结一下这个问题心愿对你有用。如果感觉还不错,记得加个关注点个赞哦 思维导图 常见的主从架构随着日益增长的访问量，单台数据库的能力曾经顾此失彼。因而采纳主库写数据，从库读数据这种将读写分来到的主从架构便随之衍生了进去。 一主一从 一主多从 一主一从和一主多从是最常见的主从架构，施行起来简略并且无效，不仅能够实现高可用，还能读写拆散，进而晋升集群的并发能力。 多主一从 双主复制 级联复制 主从同步原理想要理解主从同步原理，首先得记住两个很重要的日志文件 binlog（二进制日志文件）relay log（中继日志文件） 主从同步过程从库生成两个线程，一个I/O线程，一个SQL线程；i/o线程去申请主库 的binlog，并将失去的binlog日志写到relay log（中继日志） 文件中；主库会生成一个 log dump 线程，用来给从库 i/o线程传binlogSQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作统一，而最终数据统一； 如何判断主从是否延时通过监控 show slave status 命令输入的Seconds_Behind_Master参数的值来判断： NULL，示意io_thread或是sql_thread有任何一个产生故障；0，该值为零，示意主从复制良好；正值，示意主从曾经呈现延时，数字越大示意从库提早越重大。 主从提早起因随机重放MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，因为binlog是程序写，所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是程序的，老本高很多。所以SQL Thread线程的速度赶不上主库学binlog的速度，就会产生主从提早 锁期待另一方面，因为SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能解决的速度，或者当slave中有大型query语句产生了锁期待那么延时就产生了。 主从提早解决办法并行复制既然 SQL 单线程进行重放时速度无限，那么能不能采纳多线程的形式来进行重放呢？MySQL 5.6 版本后，提供了一种并行复制的形式，通过将 SQL 线程转换为多个 work 线程来进行重放，这样就解决了主从提早的问题 升高并发如果你了解了随机重放这个导致主从提早的起因，那么就比拟好了解了，管制主库写入的速度，主从提早产生的概率天然就小了。 读主库如果你做的是相似领取这种对实时性要求十分高的业务，那么最间接的办法就是间接读主库。 几句唠叨大家好，我是小饭，一枚后端工程师。如果感觉文章对你有一点点帮忙，欢送分享给你的敌人，也给小饭点个赞，上面是我的公众号，感兴趣能够关注，这是小饭坚持下去的能源，谢谢大家，咱们下次见！

通过这篇文章你能理解到的常识binlog 是什么binlog 的作用binlog 的三种类型，以及各自优缺点binlog 文件的构造与内容binlog 是什么Binary Log，顾名思义是一种二进制格局的日志。具体来说，binlog 日志是一组蕴含了对 MySQL server 实例进行数据批改（update/delete/insert/...）信息的文件。 binlog 作用用于复制，如主从复制数据恢复binlog 类型基于语句 (Statement-based)的日志记录 (SBL): 事件蕴含产生数据变动的SQL语句。基于行 (Row-based) 的日志记录(RBL): 形容单个行的变动混合 (Mixed)：上述两者联合应用, 以 SBL 为主，非凡状况下切换到 RBLbinlog 为什么会有这三种类型？ 一开始只有 statement-based，但 statement-based 存在不少问题，前面才有的 row 与 mixed。 SBL 长处产生的日志文件少， io 次数少SBL 毛病在一些不平安的语句上，主从复制做不到数据统一，比方 含有零碎函数的语句，可能会在正本上返回不同的值，如 RAND(), USER(),UUID(), SYSDATE() ....更新一个有 AUTO_INCREMENT 列的表Updates using LIMIT...慢 SQL 会在正本中再执行一次RBL 长处这是最平安的复制模式在 INSERT/UPDATE/DELETE 语句中，正本绝对主行锁范畴更小。RBL 毛病RBL 日志文件更大总结举荐应用 RBL，利大于弊，最新 MySQL 版本默认也是应用 RBL。 binlog 构造binlog 文件构造binlog.index : 文本文件，如上面的例子，列出了以后的二进制日志文件（当初有 6 个）。 binlog.xxxxxx: log 二进制文件， binlog.000001binlog.000002binlog.000003binlog.000004binlog.000005binlog.000006binlog.index 每个日志文件以一个 4 字节魔数 ( 0xfe b i n) 结尾，前面是一组形容数据批改的事件，文件格式如下： ...

I、索引的一些基本概念索引就是数据结构索引是为了进步数据查问效率 例子：字典。外面的声母查问形式就是聚簇索引。偏旁部首就是二级索引，偏旁部首+笔画就是联结索引。II、常见索引模型模型表列 B场景场景哈希表键-值（类比hashmap）等值查问不能范畴查问有序数组按顺序存储，用二分法查问动态存储引擎查问效率高，更新效率低搜寻树每个节点的左儿子小于父节点，父节点又小于右儿子等值和范畴查问数高过高，读写磁盘次数过多InnoDB应用B+Tree索引。InnoDB的表构造：1.在InnoDB中，每一张表其实就是多个B+树，即一个主键索引树和多个非主键索引树。2.执行查问的效率，应用主键索引>应用非主键索引>不应用索引。3.如果不应用索引进行查问，则从主索引B+树的叶子节点进行遍历。III、索引类型索引存储形式区别主键索引（聚簇索引）叶子节点存的是整行的数据只有搜寻ID这个B+Tree即可拿到数据非主键索引（二级索引）叶子节点内容是主键的值先搜寻索引拿到主键值，再到主键索引树搜寻一次从性能和存储空间方面考量，举荐应用自增主键，就能够保障新的ID肯定是在叶子节点最左边，不会影响后面的数据。IV、B+Tree索引保护一个数据页满了，依照B+Tree算法，新减少一个数据页，叫做页决裂，会导致性能降落。空间利用率升高大略50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是决裂过程的逆过程。 须要温习一下二叉树、红黑树、B+树等数据结构V、笼罩索引、前缀索引和索引下推1、笼罩索引：如果查问条件应用的是一般索引（或是联结索引的最左准则字段），查问后果是联结索引的字段或是主键，不必回表操作，间接返回后果，缩小IO磁盘读写读取正行数据2、最左前缀：联结索引的最左N个字段，也能够是字符串索引的最左M个字符（MYSQL做词法剖析语法分析的时候是通过建设最左子树来建设语法树的，解析的过程也是从左到右所以遵循最左前缀的准则。）3、联结索引：依据创立联结索引的程序，以最左准则进行where检索，比方（age，name）以age=1 或 age= 1 and name=‘张三’能够应用索引，单以name=‘张三’ 不会应用索引，思考到存储空间的问题，还请依据业务需要，将查找频繁的数据进行靠左创立索引。比方一个联结索引(a,b,c)，其实质是按a,b,c的程序拼接成了一个二进制字节数组，索引记录是按该字节数组逐字节比拟排序的，所以其是先按a排序，再按b排序，再按c排序的，至于其为什么是按最左前缀匹配的也就不言而喻了。4、索引下推：like 'hello%’and age >10 检索，MySQL5.6版本之前，会对匹配的数据进行回表查问。5.6版本后，会先过滤掉age<10的数据，再进行回表查问，缩小回表率，晋升检索速度。 VI、mysql军规给表创立索引时，应该创立哪些索引，每个索引应该蕴含哪些字段，字段的程序怎么排列，这个问题没有标准答案，须要依据具体的业务来做衡量。不过有些思路还是可供参考的：1.既然是一个衡量问题，没有方法保障所有的查问都高效，那就要优先保障高频的查问高效，较低频次的查问也尽可能的应用到尽可能长的最左前缀索引。能够借助pt-query-digest来采样统计业务查问语句的拜访频度，可能须要迭代几次能力确定联结索引的最终字段及其排序。2.业务是在演进的，所以索引也是要随着业务演进的，并不是索引建好了就高枕无忧了，业务发生变化时，咱们须要从新扫视当初建的索引是不是还仍然高效，仍然能满足业务需要。3.业内流传的有一些mysql军规，其实这些并不是真正的军规，只是典型场景下的最佳实际。真正的军规其实就一条：高效的满足业务需要。比方有个军规规定一个表上的索引数不超过5个，但如果咱们当初有一些历史数据表、历史日志表，咱们很明确的晓得这些表上不会再有数据写入了，但咱们的查问需要很多也很多样化，那咱们在这些表上的索引数能不能超过5个？当然是没有任何问题的。当然对于这份军规还是要认真看一下的，但看的重点不是去记住它，而是要弄明确每一条军规它为什么这么规定，它这样规定是基于什么思考，实用的场景和前提是什么，这些都弄明确了，你记不记得住这些军规都无所谓了，因为你曾经把它消溶到了你的血液中，具体到本人的具体业务时熟能生巧将是必然。

创立你的 Mysql 数据库 零、前言一、介绍 MySQL 设计二、数据采集三、数据命名四、数据分组五、数据结构调整六、补充案例钻研Redis 学习手册 零、序言一、NoSQL 简介二、Redis 入门三、Redis 中的数据结构和通信协议四、Redis 服务器的性能五、Redis 中的数据处理六、网络应用中的 Redis七、商业利用中的 Redis八、集群九、保护 Redis精通 MongoDB 4.x 零、前言第一局部：根本 MongoDB——设计指标和架构 一、MongoDB——古代网络数据库二、模式设计与数据建模第二局部：高效查问 三、MongoDB CRUD 操作四、高级查问五、多文档 ACID 事务六、聚合七、索引第三局部：数据管理 八、监控、备份和平安九、存储引擎十、MongoDB 工具十一、MongoDB 和大数据第四局部：扩大和高可用性 十二、正本十三、分片十四、容错和高可用性精通 PHPMyAdmin 3.4 高效 MySQL 治理 零、序言一、phpMyAdmin 入门二、配置认证和平安三、界面浏览四、创立和浏览表五、数据和构造的变更六、导出构造和数据（备份）七、构造和数据导入八、数据检索九、执行表和数据库操作十、关系零碎的劣势十一、输出 SQL 语句十二、生成多表查问十三、同步数据和反对复制十四、应用查问书签十五、文档零碎十六、应用 MIME 转换数据十七、MySQL 5 新增反对性能十八、跟踪变更十九、治理 MySQL 服务器二十、附录 A：故障排除与反对MongoDB 秘籍 零、序言一、装置和启动服务器二、命令行操作和索引三、编程语言的驱动四、治理五、高级操作六、监控与备份七、在云上部署 MongoDB八、与 Hadoop 的集成九、开源和专有工具十、附录 A：参考概念MongoDB 数据建模 零、序言一、数据建模简介二、MongoDB 数据建模三、文档查问四、索引五、优化查问六、数据管理七、扩容八、MongoDB 日志记录和实时剖析MongoDB 基础知识 零、序言一、MongoDB 简介二、文件和数据类型三、服务器和客户端四、查问文档五、插入、更新和删除文档六、应用聚合管道和数组进行更新七、数据聚合八、在 MongoDB 中编写 JavaScript九、性能十、正本十一、MongoDB 中的备份和复原十二、数据可视化十三、MongoDB 案例钻研十四、附录MySQL8 治理手册 零、前言一、MYSQL 8 简介二、装置和降级 MySQL 8三、MySQL 8——应用程序和工具四、MySQL 8 数据类型五、MySQL 8 数据库治理六、MySQL 8 存储引擎七、MySQL 8 中的索引八、MySQL 8 中的正本九、MySQL 8 中的分区十、MySQL 8——可扩展性和高可用性十一、MySQL 8——安全性十二、优化 MySQL 8十三、扩大 MySQL 8十四、MySQL 8 最佳实际和基准测试十五、MySQL 8 疑难解答MySQL8 秘籍 ...

本文首发：https://kalacloud.com/blog/how-to-manage-and-use-mysql-database-triggers 触发器（Trigger）是 MySQL 中十分实用的一个性能，它能够在操作者对表进行「增删改」 之前（或之后）被触发，主动执行一段当时写好的 SQL 代码。 本教程率领大家在实践中学习，你将学到触发器在理论利用场景中的重要利用。 在这个教程中，你是「卡拉云银行」的程序员，你正在搭建一套银行客户管理系统。在这套零碎中，你须要设置在INSERT 表之前检测操作者是否输出谬误数据、在 UPDATE 时，记录操作者的行为 log ，以及在DELETE 时，判断删除的信息是否合乎删除规定。 这三类操作都能够应用 MySQL 触发器来实现。 如果你正在数据库的根底上搭建一套数据库管理工具或企业外部工具，举荐你试试我开发的卡拉云，详情见后文。 本教程将带你一起实际的案例 BEFORE INSERT ： 在插入数据前，检测插入数据是否合乎业务逻辑，如不合乎返回错误信息。AFTER INSERT ： 在表 A 创立新账户后，将创立胜利信息主动写入表 B 中。BEFORE UPDATE ：在更新数据前，检测更新数据是否合乎业务逻辑，如不合乎返回错误信息。AFTER INSERT ：在更新数据后，将操作行为记录在 log 中BEFORE DELETE ：在删除数据前，查看是否有关联数据，如有，进行删除操作。AFTER DELETE ：删除表 A 信息后，主动删除表 B 中与表 A 相关联的信息。先决条件在开始之前，请确保您具备以下条件： 一台配置好的 Ubuntu 服务器，root 账号。服务器上配置好 MySQL Server（配置 MySQL 请看MySQL装置及连贯MySQL教程）MySQL root 账号创立示例数据库咱们先创立一个洁净的示例数据库，不便大家能够追随本教程一起实际。咱们会在这个数据库中演示 MySQL 触发器的多种工作形式。 首先，以 root 身份登录到你的 MySQL 服务器： mysql -u root -p呈现提醒时，请输出你 MySQL root 账号的明码，而后点击 ENTER 持续。看到 mysql> 提醒后，运行以下命令，创立 demo_kalacloud 数据库： ...

当客户端连贯 MySQL 服务器时，必须提供无效的身份认证，例如用户名和明码。当用户执行任何数据库操作时，服务器将会验证用户是否具备相应的权限，例如查问表须要 SELECT 权限，删除对象须要 DROP 权限。 为了不便用户权限的治理，MySQL 8.0 提供了角色的性能。角色（Role）是一组权限的汇合。 本篇咱们探讨 MySQL 中的账户和权限的治理。 5.1 治理用户5.1.1 创立用户MySQL 应用 CREATE USER 语句创立用户，根本语法如下： CREATE USER [IF NOT EXISTS] account_nameIDENTIFIED BY 'password';其中，account_name 是账户名称；账户名称分为两个局部：用户名（user_name）和主机名（host_name），应用 % 连贯。IDENTIFIED BY 用于指定用户的明码。IF NOT EXISTS 用于防止创立重名账户时产生错误信息。 以下语句创立一个新的用户 dev01，它能够从本机登录（localhost）： mysql> CREATE USER dev01@localhost IDENTIFIED BY 'Dev01@mysql';Query OK, 0 rows affected (0.21 sec)MySQL 中的账户由用户名和主机名独特决定，主机 office.example.com 上的 dev01 和主机 home.example.com 上的 dev01 是两个账户。如果不指定主机名，示意用户能够从任何主机登录： user_nameuser_name@%% 是通配符，示意任何字符串；另外，_ 示意任意单个字符。 如果用户名或主机名中蕴含特殊字符，例如空格或者 - ，须要应用引号别离援用这两局部内容： 'user-name'@'host-name'除了单引号之外，也能够应用反引号（`）或者双引号（"）。 MySQL 中的账户信息存储在零碎数据库 mysql 的 user 表中： ...

在日常的数据库保护工作中，常常须要对数据库进行导入导出操作，备份、剖析、迁徙数据都须要用到导入导出性能，在本教程中将具体解说所有常见的 MySQL 和 MariaDB 中导入导出数据的办法（留神：MySQL 和 MariaDB 两个数据库操作命令一样，能够调换。） 本教程将具体解说1. MySQL / MariaDB 数据库数据「导出」（1）应用 mysqldump间接导出数据至 SQL 文件 （2）阿里云 / 腾讯云近程服务器中的数据库间接导出到本地计算机 （3）应用 into outfile命令导出数据至 CSV / Excel 提醒：如果你正在寻找数据迁徙计划，请查看我写的的另一篇专门针对 MySQL 数据迁徙的教程，教程中蕴含腾讯云、阿里云迁徙实战。 2. MySQL / MariaDB 数据库数据「导入」（1）将 SQL 文件导入至 MySQL / MariaDB 数据库中 （2）应用 source 导入数据库 SQL 文件 （3）将 CSV / Excel 文件 导入至 MySQL / MariaDB 数据库中 3. 应用「卡拉云」一键导入导出 MySQL / MariaDB 数据如何应用卡拉云，5分钟搭建一套适应本人工作流的一键导入导出数据库系统。卡拉云无需部署，即插即用，可依据需要灵便调配，实用于后端工程师疾速搭建企业外部零碎、数据产品经理查看剖析数据，数据分析师依据需要疾速搭建数据共享平台分享给组内同学协同查看等利用场景。点这里看详情。 4. 先决条件追随本教程学习如何导入导出 MySQL 或 MariaDB 数据库，首先要有 一台 Linux 服务器，本文以 Ubuntu 为例已装置 MySQL 或 MariaDB server （还未装置，装置教程请看这篇《MySQL 装置教程》）MySQL 或 MariaDB Server 中有数据库（用于导出）教程应用 MacOS 演示本地计算机操作，此操作同时实用于 Windows 及 Linux一. 导出 MySQL 或 MariaDB 数据库1.如何应用 mysqldump 导出数据mysqldump 命令是数据库导出中应用最频繁对一个工具，它可将数据库中的数据备份成已 *.sql 结尾的文本文件，表构造和数据都会存储在其中。 ...

本文次要通过批量与非批量比照操作的形式介绍MongoDB的bulkWrite()办法的应用。顺带与关系型数据库MySQL进行比照，比拟这两种不同类型数据库的效率。如果只是想学习bulkWrite()的应用的看第一局部就行。 测试环境：win7旗舰版、16G内存、i3处理器、MongoDB3.0.2、mysql5.0一、MongoDB批量操作MongoDB对数据的操作分为Read Operations和Write Operations，Read Operations蕴含查问操作，Write Operations蕴含删除、插入、替换、更新几种操作。MongoDB提供客户端用bulk形式执行Write Operations，也就是批量写操作。在java driver中，对应MongoCollection的bulkWrite()办法，先来看下这个办法签名： BulkWriteResult com.mongodb.client.MongoCollection.bulkWrite(List<? extends WriteModel<? extends Document>> requests)这个办法要求传入一个List汇合，汇合中的元素类型为WriteModel，它示意一个可用于批量写操作的基类模型，它有以下几个子类DeleteManyModel、DeleteOneModel、 InsertOneModel、ReplaceOneModel、 UpdateManyModel、UpdateOneModel，从名字能够看进去它对应了删除、插入、替换、更新几种操作。该办法返回一个BulkWriteResult对象，代表一个胜利的批量写操作后果，封装了操作后果的状态信息，如插入、更新、删除记录数等。 1、插入操作 (1)、批量插入 代码如下，该办法接管一个蕴含要进行插入的Document对象的汇合参数，遍历汇合，应用Document结构InsertOneModel对象，每个InsertOneModel实例代表一个插入单个Document的操作，而后将该实例增加List汇合中，调用bulkWrite()办法，传入存储所有插入操作的List汇合实现批量插入。 public void bulkWriteInsert(List<Document> documents){ List<WriteModel<Document>> requests = new ArrayList<WriteModel<Document>>(); for (Document document : documents) { //结构插入单个文档的操作模型 InsertOneModel<Document> iom = new InsertOneModel<Document>(document); requests.add(iom); } BulkWriteResult bulkWriteResult = collection.bulkWrite(requests); System.out.println(bulkWriteResult.toString());}测试：上面通过一个main函数测试下。首先结构10万个Product实体对象，应用一个工具类将其转换成json字符串，而后解析成Document对象，保留到一个list汇合中，而后调用下面编写的办法测试10万个对象插入工夫。 TestMongoDB instance = TestMongoDB.getInstance();ArrayList<Document> documents = new ArrayList<Document>();for (int i = 0; i < 100000; i++) { Product product = new Product(i,"书籍","追风筝的人",22.5); //将java对象转换成json字符串 String jsonProduct = JsonParseUtil.getJsonString4JavaPOJO(product); //将json字符串解析成Document对象 Document docProduct = Document.parse(jsonProduct); documents.add(docProduct);}System.out.println("开始插入数据。。。");long startInsert = System.currentTimeMillis();instance.bulkWriteInsert(documents);System.out.println("插入数据实现，共耗时："+(System.currentTimeMillis() - startInsert)+"毫秒");后果：1560毫秒，屡次测试根本在1.5秒左右 ...

表（Table）是数据库存储数据的次要模式，由行（Row）和列（Column）组成，相似于常见的电子表格。 MySQL 中的表与其余数据库的最大区别在于它们能够应用不同的存储引擎（Storage Engine）。存储引擎是 MySQL 中用于治理、拜访和批改物理数据的组件，不同的存储引擎提供了不同的性能和个性。 从 MySQL 5.5 开始，默认应用 InnoDB 存储引擎；反对事务处理（ACID）、行级锁定、故障复原、多版本并发管制（MVCC）以及外键束缚。大多数状况下，举荐应用默认的 InnoDB 存储引擎。 4.1 创立表CREATE TABLE语句用于创立表，根本的语法如下： CREATE TABLE [IF NOT EXISTS] table_name( column1 data_type column_constraint, column2 data_type, ..., table_constraints) ENGINE=storage_engine;其中，table_name 指定了新建的表名，表名在数据库中必须惟一。如果该表曾经存在，零碎将会提醒谬误；此时能够应用 IF NOT EXISTS 选项，创立之前查看是否曾经存在同名的表，防止产生错误信息。 而后，在括号中指定字段的名称、数据类型以及字段束缚；多个字段应用逗号进行分隔。常见的数据类型包含数字（INT、NUMERIC 等）、字符（VARCHAR、CHAR 等）以及日期工夫（DATE、TIME 等）。 字段束缚包含非空（NOT NULL）束缚、惟一（UNIQUE）束缚、主键（PRIMARY KEY）束缚、外键（FOREIGN KEY）束缚以及查看（CHECK）束缚以及默认值（DEFAULT）。在字段定义的最初，能够定义表的束缚。表级束缚包含：惟一（UNIQUE）束缚、主键（PRIMARY KEY）束缚、外键（FOREIGN KEY）束缚以及查看（CHECK）束缚。 对于 MySQL 束缚的具体介绍，能够参考这篇文章。最初，应用 ENGINE 选项为表指定一个存储引擎。例如 InnoDB、MyISAM、MEMORY、ARCHIVE 等，不指定的话默认为 InnoDB。 应用 show engines; 命令能够查看以后 MySQL 数据库反对的存储引擎。以下语句用于创立一个名为 users 的用户表： CREATE TABLE users( user_id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(50) NOT NULL, email VARCHAR(256) NOT NULL, status TINYINT NOT NULL, created_on TIMESTAMP NOT NULL, last_login TIMESTAMP, CONSTRAINT uk_email UNIQUE (email));其中，user_id 是一个主动增长的整数，并且是该表的主键。AUTO_INCREMENT 示意主动增长列，插入数据时不须要提供该字段的值，MySQL 主动生成一个从 1 开始的数字序列值。每个表只能有一个主动增长的字段。 ...

Join 是 SQL 中的罕用操作。在理论的数据库利用中，咱们常常须要从多个数据表中读取数据，这时咱们就能够应用 SQL 语句中的连贯（join），在两个或多个数据表中查问数据。 罕用 Join 算法罕用的多表连贯算法次要有三类，别离是 Nested-Loop Join、Hash Join 和 Sort Merge Join。 Nested-Loop JoinSimple Nested-Loop Join 是最简略粗犷的 Join 算法 ，即通过双层循环比拟数据来取得后果，然而这种算法显然太过于粗鲁，如果每个表有 1 万条数据，那么对数据比拟的次数=1万 * 1万 =1亿次，很显然这种查问效率会十分慢。 在 Simple Nested-Loop Join 算法的根底上，延申出了 Index Nested-Loop Join 和 block Nested-Loop Join。前者通过缩小内层表数据的匹配次数优化查问效率；后者则是通过一次性缓存外层表的多条数据，以此来缩小内层表的扫表次数，从而达到晋升性能的目标。 Batched Key Access Join (BKA Join) 能够看作是一个性能优化版的 Index Nested-Loop Join。之所以称为 Batched，是因为它的实现应用了存储引擎提供的 MRR（Multi-Range Read） 接口批量进行索引查问，并通过 PK 排序的办法，将随机索引回表转化为程序回表，肯定水平上减速了查索引的磁盘 IO。 Hash Join两个表若是元组数目过多，一一遍历开销就很大，Hash Join（哈希连贯）是一种进步连贯效率的办法。哈希连贯次要分为两个阶段：建设阶段（build phase)和探测阶段（probe phase)。 在建设阶段，首先抉择一个表（个别状况下是较小的那个表，以缩小建设哈希表的工夫和空间），对其中每个元组上的连贯属性（join attribute)采纳哈希函数失去哈希值，从而建设一个哈希表。 在探测阶段，对另一个表，扫描它的每一行并计算连贯属性的哈希值，与 bulid phase 建设的哈希表比照，若有落在同一个 bucket 的，如果满足连贯谓词（predicate)则连接成新的表。 ...

从零开始学MYSQL - MYSQL装置前言 这个专栏也能够认为是学习笔记，因为之前的专栏学习的是网络上的培训机构教程，学习实现之后发现尽管讲到一些有一些深刻的货色，然而讲的都不是特地深，所以从这一节开始将会从零开始来全盘理解MYSQL，这里找了一本书《从根上了解Mysql》，集体也非常举荐读者去看看这边书，不仅有新个性对接解说，也有很多的干货，同时讲的也非常好，作为反对集体前面也买了一本实体书（尽管根本都是拿pdf看的）。 思维导图（继续更新）https://www.mubucm.com/doc/7D... 图片地址：https://gitee.com/lazyTimes/i... 参考资料：英文mysql5.7官网文档：https://dev.mysql.com/doc/ref...中文对应翻译网站（机翻）：https://www.docs4dev.com/docs...概述意识mysql的客户端和服务端是怎么一回事理解装置mysql的注意事项，以及回顾mysql集体简要介绍对于mysql启动的常见四个命令以及具体的作用 mysqldmysqld_safemysql.servermysqld_multi意识客户端和服务端 因为是Mysql的专栏，这里就不牵扯下面TCP/IP，什么网络传输协定了，总之咱们只须要理解mysql是分为客户端和服务端的，通常咱们拜访页面或者浏览数据就是一次数据库的拜访过程（当然当初少数货色都动态化了），所以连贯的这一方被称为客户端而承受申请的这一方面被称为服务端。 mysql的根本工作通常咱们应用MYSQL根本都是干这些事件： 连贯数据库。查询数据库的数据，客户端发送申请给服务端，服务端依据命令找到数据回送给客户端。和数据库断开连接。mysql实例 说完了下面的废话之后，咱们来说下mysql实例，实例也在操作系统的层面叫做过程，而过程能够看做是处理器，内存，IO设施的形象，咱们不须要晓得这个过程底层是如何传输数据存储数据的，咱们只须要理解他须要一个端口，并且每一个实例都有一个 过程ID的货色，在数据库实例运行的时候零碎会调配一个过程ID给它并且保障惟一，而每一个过程都有本人的名字，这个名称是装置的时候由程序员本人设置的，然而如果没有调配则会应用MYSQL本人默认设置的名称。 咱们启动的 MySQL 服务器过程的默认名称为 mysqld ， 而咱们罕用的 MySQL 客户端过程的默认名称为 mysql 。 从这个名称咱们也能够揣测出为什么咱们启动一个服务通常会应用Mysqld，而咱们连贯数据库通常应用mysql。 每一个文件就是对于IO设施的形象虚拟内存是对内存和IO设施的形象过程：则是对处理器，虚拟内存和IO设施的形象装置Mysql的注意事项 装置Mysql其实是一件非常简略然而实际上如果全手动装置细节还是比拟多的，通常状况下咱们本人应用间接用EXE程序或者间接应用BIN包等，但很多时候对于Linux的软件很多人都会举荐应用 源码装置，源码装置的益处不仅仅是放大体积，通过不少的试验证实源码的装置形式效率会有所晋升，所以正式环境下 尽可能应用源码装置，最初须要留神的一点是：Linux下应用RPM包会有独自的服务器和客户端RPM包，须要别离装置。 装置目录地位的区别 上面是具体的Mysql装置目录，当然上面这里只做参考，集体mac电脑应用的是brew install mysql加上m1的的芯片装置的，适配性未知，所以为了保障笔记的牢靠，这里用回了windows零碎来进行理论测试和演练，上面是不同的操作系统在mysql的装置目录存储地位存在轻微的不同，然而肯定要非常分明mysql实在的装置地位，这对于本人捣鼓各种命令以及设置参数很重要。 macOS 操作系统上的装置目录：/usr/local/mysql/Windows 操作系统上的装置目录：C:\Program Files\MySQL\MySQL Server 5.7Mysql装置windows装置过程 装置过程就不演示了，网上的教程一抓一大把，为了稳当起见这里集体应用的mysql版本是5.7的版本，同时应用了默认exe程序安装，如果你应用了mysql-installxx.exe装置，有的时候会呈现上面的命令： 'mysql' 不是外部或外部命令，也不是可运行的程序 看到这个提醒之后，第一反馈是进入power shell的管理员模式： PS C:\Windows\system32> mysql -uroot -pmysql : 无奈将“mysql”项辨认为 cmdlet、函数、脚本文件或可运行程序的名称。请查看名称的拼写，如果包含门路，请确保门路正确，而后再试一次。所在位置 行:1 字符: 1+ mysql -uroot -p+ ~~~~~ + CategoryInfo : ObjectNotFound: (mysql:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException 发现还是报错，而后我跑去服务看了下mysql是否有启动，发现mysql又是启动的，这里有点奇怪。 ...

从零开始学Mysql - 连贯治理和存储引擎前言 本篇为集体mysql专栏的第二篇，第二篇将会是对于连贯治理以及存储引擎的探讨，以及mysql底层的交互过程，这个概念在之前的mysql专栏中有提到过，这里再一次进行总结，在第一篇开篇的时候探讨过这个专栏的内容大多数都是参考《从根上了解Mysql》这本书，这里再次强调一遍，后续专栏文章不会再进行赘述。 概述客户端和服务端的连贯过程 Tcp/ip 形式：重点为IP地址和端口命名管道和共享内存：window独有的连贯形式，然而没什么鸟用，不必理睬Unix域套接字文件：如果服务端批改套接字的默认监听文件mysql申请解决流程 连贯治理：服务端接口客服端的查问sql语句查问优化：次要工作为拆解命令并对命令进行“编译”存储引擎：通过对外接口API接受命令并且查问数据存储引擎介绍 存储引擎介绍批改存储引擎Mysql连贯连贯形式Tcp/IP Tcp是一种网络的通信协议，通常咱们只须要关注两个参数，IP和端口，IP地址能够看作门牌号，而端口能够看作应用程序的入口，进行网络通信须要IP和端口号能力实现，而端口号的范畴通常为0-65535，有了IP地址和端口之后咱们既能够进行mysql连贯了，日常应用中最常见的mysql -uroot -pxxx命令，这一条命令的连贯形式理论就是一种TCP/IP的连贯形式。 Mysql如果在装置过程不进行其余改变的状况下默认占用3306的端口，客户端中咱们连贯的时候能够通过mysql -P3307中的-P参数进行端口的指定，而服务端的启动则能够应用mysqld -P3307指定用其余的端口启动一个mysql的服务端服务，留神不要看花眼了，下面的参数客户端是mysql而服务端是mysqld。 集体比拟举荐端口的抉择上在软件默认的端口后面加个1，比方mysql的默认端口3306举荐应用13306，这样能够无效的躲避可能存在的和其余的应用程序的端口占用或者抵触，并且能够发现其实大多数的中间件或者框架都是应用1万以内的端口。 命名管道和共享内存 这个形式次要针对window用户，客户端和服务端之间能够应用叫做命名管道或者共享内存的形式进行连贯，因为这个货色 不重要所以简略理解即可，另外依据官网文档的介绍这种连接符形式要比TCP/IP的连贯形式快30%-50%。 命名管道：因为Mysql默认是不启用这个命名管道的形式的，须要在启动服务器程序的命令中加上 --enable-named-pipe 参数，而后在启动客户端程序的命令中退出 --pipe或者 --protocol=pipe 参数，或者咱们在my.ini 文件当中对于上面的内容进行批改： MySQL 默认是不启用命名管道连贯形式，启用办法：[mysqld]enable-named-pipesocket=MySQL 最初给出一个简略的JAVA例子理解如何配置链接即可，外围局部为：socketFactory=com.mysql.jdbc.NamedPipeSocketFactory： public class MySQLNamedPipeTester { public static void main(String[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver").newInstance(); Connection conn = DriverManager.getConnection( "jdbc:mysql:///oschina?socketFactory=com.mysql.jdbc.NamedPipeSocketFactory", "root", "xxxx"); PreparedStatement ps = conn.prepareStatement("SELECT COUNT(*) FROM xxxx"); ResultSet rs = ps.executeQuery(); while(rs.next()){ System.out.println(rs.getInt(1)); } //conn.close(); }} 共享内存：共享内存的连贯形式必须保障客户端和服务端过程在同一个Windows主机，否则是无奈失效的，共享内存的形式是在启动服务器程序的命令中加上 --shared-memory 参数，并且进行重新启动之后即可，不过咱们也能够在客户端的命令当中退出相似--protocol=memory参数来指定应用共享内存的形式通信。 ...

什么是Online DDLInnodb存储引擎中，DML语句会在表上加MDL(Meta data Lock)读锁，DDL语句会在表上加MDL写锁，MDL锁是表锁。 MDL读锁是共享的，MDL读锁与MDL写锁、MDL写锁与MDL写锁是互斥的；也就是说，在DDL语句执行过程中，持有MDL写锁，此时会阻塞新的select/update申请(因为要申请MDL读锁)。 当DDL语句执行须要很长时间时，前面的DML语句就会迟迟得不到执行。 为了解决这个问题，MySQL5.6减少了Online DDL的个性：当执行DDL语句时，先申请MDL写锁，而后MDL写锁进化为MDL读锁，此时便不再阻塞DML语句，这也是DDL被称为Online的起因。 Online DDL仅在开始时申请MDL写锁，而后再具体的数据操作之前，MDL写锁-->MDL读锁，因为数据操作是占用绝大部分工夫的，故总体上看该DDL是Online的。 Online DDL的利用：重建表咱们晓得，delete删除表中的某些记录行，仅仅将这些记录“标记”为已删除、可复用，并不会让.ibd文件变小。 为了解决这个问题，能够应用重建表的命令，让表空间更“紧凑”： alter table t engine=innodb,ALGORITHM=inplace;该语句的执行过程： 建设临时文件tmp_file，扫描表t主键索引上的所有page；将表t上的记录生成新的B+Tree，存储到tmp_file中；在生成tmp_file过程中，若表t上有DML操作，将其记录到row-log中；在tmp_file生成后，将row-log apply到tmp_file，生成新的表数据；用tmp_file替换t的.ibd文件； Online DDL的利用：在线加索引在业务运行过程中，发现某些查问很慢，须要在线给表加索引： alter table t add index idx_aaa(`a`);该DDL语句同样能够反对Online DDL，加索引的过程中，不影响表上DML语句的执行。 并不是增加所有的索引都是Online DDL，比方增加全文索引FULLTEXT index就不反对。 参考：1.MySQL实战45讲

一、数据库瓶颈不论是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的沉闷连接数减少，进而迫近甚至达到数据库可承载沉闷连接数的阈值。在业务Service来看就是，可用数据库连贯少甚至无连贯可用。接下来就能够设想了吧(并发量、吞吐量、解体)。 1、IO瓶颈第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查问时会产生大量的IO，升高查问速度 -> 分库和垂直分表。第二种：网络IO瓶颈，申请的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈第一种：SQL问题，如SQL中蕴含join，group by，order by，非索引字段条件查问等，减少CPU运算的操作 -> SQL优化，建设适合的索引，在业务Service层进行业务计算。第二种：单表数据量太大，查问时扫描的行太多，SQL效率低，CPU率先呈现瓶颈 -> 程度分表。 二、分库分表1、程度分库 概念：以字段为根据，依照肯定策略(hash、range等)，将一个库中的数据拆分到多个库中。后果： 每个库的构造都一样;每个库的数据都不一样，没有交加;所有库的并集是全量数据;场景：零碎相对并发量上来了，分表难以基本上解决问题，并且还没有显著的业务归属来垂直分库。剖析：库多了，io和cpu的压力天然能够成倍缓解。 2、程度分表 概念：以字段为根据，依照肯定策略(hash、range等)，将一个表中的数据拆分到多个表中。 后果： 每个表的构造都一样;每个表的数据都不一样，没有交加;所有表的并集是全量数据;场景：零碎相对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，减轻了CPU累赘，以至于成为瓶颈。举荐：一次SQL查问优化原理剖析剖析：表的数据量少了，单次SQL执行效率高，天然加重了CPU的累赘。 3、垂直分库 概念：以表为根据，依照业务归属不同，将不同的表拆分到不同的库中。 后果： 每个库的构造都不一样;每个库的数据也不一样，没有交加;所有库的并集是全量数据;场景：零碎相对并发量上来了，并且能够形象出独自的业务模块。剖析：到这一步，基本上就能够服务化了。例如，随着业务的倒退一些专用的配置表、字典表等越来越多，这时能够将这些表拆到独自的库中，甚至能够服务化。再有，随着业务的倒退孵化出了一套业务模式，这时能够将相干的表拆到独自的库中，甚至能够服务化。 4、垂直分表 概念：以字段为根据，依照字段的活跃性，将表中字段拆到不同的表(主表和扩大表)中。 后果： 每个表的构造都不一样;每个表的数据也不一样，一般来说，每个表的字段至多有一列交加，个别是主键，用于关联数据;所有表的并集是全量数据;场景：零碎相对并发量并没有上来，表的记录并不多，然而字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行缩小，查问时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。剖析：能够用列表页和详情页来帮忙了解。垂直分表的拆分准则是将热点数据(可能会冗余常常一起查问的数据)放在一起作为主表，非热点数据放在一起作为扩大表。这样更多的热点数据就能被缓存下来，进而缩小了随机读IO。拆了之后，要想取得全副数据就须要关联两个表来取数据。但记住，千万别用join，因为join不仅会减少CPU累赘并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据，应该在业务Service层做文章，别离获取主表和扩大表数据而后用关联字段关联失去全副数据。 三、分库分表工具sharding-sphere：jar，前身是sharding-jdbc;TDDL：jar，Taobao Distribute Data Layer;Mycat：中间件。注：工具的利弊，请自行调研，官网和社区优先。四、分库分表步骤依据容量(以后容量和增长量)评估分库或分表个数 -> 选key(平均)-> 分表规定(hash或range等)-> 执行(个别双写)-> 扩容问题(尽量减少数据的挪动)。 五、分库分表问题1、非partition key的查问问题基于程度分库分表，拆分策略为罕用的hash法。端上除了partition key只有一个非partition key作为条件查问 映射法 基因法 注：写入时，基因法生成user_id，如图。对于xbit基因，例如要分8张表，23=8，故x取3，即3bit基因。依据user_id查问时可间接取模路由到对应的分库或分表。 依据user_name查问时，先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成罕用snowflake算法。 端上除了partition key不止一个非partition key作为条件查问 映射法 冗余法 注：依照order_id或buyer_id查问时路由到db_o_buyer库中，依照seller_id查问时路由到db_o_seller库中。感觉有点轻重倒置!有其余好的方法吗?扭转技术栈呢?后盾除了partition key还有各种非partition key组合条件查问 NoSQL法 冗余法 2、非partition key跨库跨表分页查问问题基于程度分库分表，拆分策略为罕用的hash法。 注：用NoSQL法解决(ES等)。3、扩容问题基于程度分库分表，拆分策略为罕用的hash法。 程度扩容库 (降级从库法) 注：扩容是成倍的。程度扩容表(双写迁徙法) ...

因为工作的起因，我有机会认真用过市面上简直所有的 MySQL 管理工具，对各家的数据库管理软件的个性有了全面的理解。 我大略用了 20+ 款 MySQL 管理工具，从种挑出 10 款最棒的写了明天的测评。其中 7 款收费或有社区免费版，另外 3 种是付费版。 当初，在钻研这些工具时，我发现网上那些所谓的测评举荐文章里，简直没人真用过本人文章中写的软件，都是云测评。 过后就想本人把所有软件都用一遍，找机会写一篇深度横向测评文章，帮忙抉择艰难症患者，选到最合适大家当下工作场景的工具，节省时间。本文所写软件，我都用过。 Mac 下的 MySQL 管理软件 最好用的 10 款 MySQL 管理工具测评概览MySQL Workbench - 收费、官网、有付费软件才有的重型性能Sequel Pro - 收费、玲珑、轻量级、Mac OnlyBeekeeper Studio - 收费、玲珑、跨平台、多数据库反对HeidiSQL - 收费 Win Linux only 功能丰富直给 有中文版DBeaver - 收费 玲珑、跨平台、性能大合集式，多数据库 有中文版phpMyadmin - 收费、跨平台在线版、简略间接，上手快卡拉云 - 收费、无需装置 跨平台 多数据库反对 灵便搭建 定制开发 新一代Navicat - 付费、跨平台、稳固、重型性能、有中文版dbForge Studio - 付费 Win only 稳固 产品逻辑扎实SQLyog - 付费 Win Only 付费中的精美版 中文版以上这 10 款是我从市面上 20+ 款中精简进去的，它们再也不能精简了，属于各有各的特色。 ...

MySQL 中的数据库（Database）就像是一个容器，其中蕴含了各种对象。例如，数据表（Table）、视图（View）、存储过程（Stored Procedure）以及触发器（Trigger）等。其中，表是存储数据的次要对象。它们之间的关系如下图所示： 本篇次要介绍数据库的创立、查看、抉择和删除操作，包含应用 mysql 命令行和 MySQL Workbench 图形工具两种形式。 3.1 通过 mysql 命令行治理数据库存储数据须要先创立表，而创立表之前须要创立数据库。咱们先应用 mysql 命令行客户端登录数据库，点击开始菜单 -> “MySQL” -> “MySQL 8.0 Command Line Client”，输出 root 用户明码： 3.1.1 创立数据库MySQL 中应用CREATE DATABASE语句创立一个新的数据库： CREATE DATABASE [IF NOT EXISTS] dbname;其中，dbname 指定了新数据库的名称；IF NOT EXISTS是一个可选项，如果创立的数据库曾经存在，应用该选项能够防止提醒错误信息；数据库名称必须惟一。 举例来说，以下语句用于创立一个名为 hrdb 的数据库： mysql> CREATE DATABASE hrdb;Query OK, 1 row affected (0.27 sec)那么，如何查看咱们创立的数据库呢？MySQL 提供了SHOW DATABASES命令（不辨别大小写）能够列出零碎中的所有数据库： mysql> SHOW DATABASES;+--------------------+| Database |+--------------------+| hrdb || information_schema || mysql || performance_schema || sakila || sys || world |+--------------------+7 rows in set (0.03 sec)其中，information_schema、mysql、performance_schema 以及 sys 是 MySQL 的零碎数据库。sakila 和 world 是咱们装置的示例数据库。hrdb 是刚刚新建的数据库。显然，一个 MySQL 实例服务能够治理多个数据库。 ...

1.首先去官网查看适合的版本,这里我抉择社区版. 这里抉择的是rpm捆绑包 进入linux usr/local目录下 创立文件夹mysql执行下载命令 wget https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.23-1.sles12.x86_64.rpm-bundle.tar下载实现后解压tar xf mysql-5.7.23-1.sles12.x86_64.rpm-bundle.tar依照以下程序顺次执行rpm -ivh mysql-community-common-5.7.23-1.sles12.x86_64.rpmrpm -ivh mysql-community-libs-5.7.23-1.sles12.x86_64.rpmrpm -ivh mysql-community-client-5.7.23-1.sles12.x86_64.rpmrpm -ivh mysql-community-server-5.7.23-1.sles12.x86_64.rpm为了增强安全性，MySQL5.7为root用户随机生成了一个明码，如果装置的是RPM包，则默认是在/var/log/mysqld.log中。 可通过# grep "temporary password" /var/log/mysqld.log 命令获取MySQL的长期明码笔者这里则是在/var/log/mysql/mysqld.log中找到的 奇怪的是 我用了这个长期明码始终在出错 最初用以后登录用户的管理员明码才胜利? what fuck? 不晓得是穿梭了还是 之前改过(本虚拟机环境简单)大家如果还是登陆不了能够参考一下下列链接https://www.cnblogs.com/kings...https://www.jb51.net/article/... 最初则是配置好my.cnf文件 重启mysql 即可 卸载mysql查问是否装置了mysql rpm -qa | grep mysql 卸载相干依赖 rpm -e --nodeps mysql-libs-5.1.73-7.el6.x86_64

装置Homebrewhttps://brew.sh/ brew -v# 查看 homebrew 是否可用brew doctor装置mysql 5.7# 搜寻 mysql 版本brew search mysql# 装置 5.7brew install mysql@5.7# 配置环境变量，如下图红框1echo 'export PATH="/opt/homebrew/opt/mysql@5.7/bin:$PATH"' >> ~/.zshrc# 使配置失效source ~/.zshrc# 启动 mysql 服务mysql.server start mysql 设置明码mysql装置完是没有配置明码的，MySQL 被配置为默认只容许来自 localhost 的连贯 # 输出装置后，提醒的批改明码的命令mysql_secure_installation# 无奈设置简略明码，减少了明码强度验证插件validate_password ... Failed! Error: Your password does not satisfy the current policy requirements# 查看 验证明码策略mysql> select @@validate_password_policy;+----------------------------+| @@validate_password_policy |+----------------------------+| LOW |+----------------------------+# 查看 msyql明码相干的几个全局参数mysql> SHOW VARIABLES LIKE 'validate_password%';+--------------------------------------+-------+| Variable_name | Value |+--------------------------------------+-------+| validate_password_check_user_name | OFF || validate_password_dictionary_file | || validate_password_length | 8 || validate_password_mixed_case_count | 1 || validate_password_number_count | 1 || validate_password_policy | LOW || validate_password_special_char_count | 1 |+--------------------------------------+-------+# 批改mysql参数配置mysql> set global validate_password_mixed_case_count=0;mysql> set global validate_password_number_count=0;mysql> set global validate_password_special_char_count=0;mysql> set global validate_password_length=3;# 查看 是否批改胜利mysql> SHOW VARIABLES LIKE 'validate_password%';# 批改明码mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('root');

转载至公众号：58到家沈剑，原文链接戳此 以下为转载内容：军规实用场景：并发量大、数据量大的互联网业务 军规：介绍内容 解读：解说起因，解读比军规更重要 一、根底标准 （1）必须应用InnoDB存储引擎解读：反对事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高 （2）必须应用UTF8字符集 解读：万国码，无需转码，无乱码危险，节俭空间 （3）数据表、数据字段必须退出中文正文 解读：N年后谁tm晓得这个r1,r2,r3字段是干嘛的 （4）禁止应用存储过程、视图、触发器、Event 解读：高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的状况下，这些性能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，可能轻易实现“增机器就加性能”。数据库善于存储与索引，CPU计算还是上移吧 （5）禁止存储大文件或者大照片 解读：为何要让数据库做它不善于的事件？大文件和照片存储在文件系统，数据库里存URI多好 二、命名标准 （6）只容许应用内网域名，而不是ip连贯数据库 （7）线上环境、开发环境、测试环境数据库内网域名遵循命名标准 业务名称：xxx 线上环境：dj.xxx.db 开发环境：dj.xxx.rdb 测试环境：dj.xxx.tdb 从库在名称后加-s标识，备库在名称后加-ss标识 线上从库：dj.xxx-s.db 线上备库：dj.xxx-sss.db （8）库名、表名、字段名：小写，下划线格调，不超过32个字符，必须见名知意，禁止拼音英文混用 （9）表名t_xxx，非惟一索引名idx_xxx，惟一索引名uniq_xxx 三、表设计规范 （10）单实例表数目必须小于500 （11）单表列数目必须小于30 （12）表必须有主键，例如自增主键 解读： a）主键递增，数据行写入能够进步插入性能，能够防止page决裂，缩小表碎片晋升空间和内存的应用 b）主键要抉择较短的数据类型， Innodb引擎一般索引都会保留主键的值，较短的数据类型能够无效的缩小索引的磁盘空间，进步索引的缓存效率 c） 无主键的表删除，在row模式的主从架构，会导致备库夯住 （13）禁止应用外键，如果有外键完整性束缚，须要利用程序控制 解读：外键会导致表与表之间耦合，update与delete操作都会波及相关联的表，非常影响sql 的性能，甚至会造成死锁。高并发状况下容易造成数据库性能，大数据高并发业务场景数据库应用以性能优先 四、字段设计规范 （14）必须把字段定义为NOT NULL并且提供默认值 解读： a）null的列使索引/索引统计/值比拟都更加简单，对MySQL来说更难优化 b）null 这种类型MySQL外部须要进行非凡解决，减少数据库解决记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的解决性能会升高很多 c）null值须要更多的存储空，无论是表还是索引中每行中的null的列都须要额定的空间来标识 d）对null 的解决时候，只能采纳is null或is not null，而不能采纳=、in、<、<>、!=、not in这些操作符号。如：where name!=’shenjian’，如果存在name为null值的记录，查问后果就不会蕴含name为null值的记录 （15）禁止应用TEXT、BLOB类型 解读：会节约更多的磁盘和内存空间，非必要的大量的大字段查问会淘汰掉热数据，导致内存命中率急剧升高，影响数据库性能 （16）禁止应用小数存储货币 解读：应用整数吧，小数容易导致钱对不上 （17）必须应用varchar(20)存储手机号 解读： a）波及到区号或者国家代号，可能呈现+-() b）手机号会去做数学运算么？ c）varchar能够反对含糊查问，例如：like“138%” （18）禁止应用ENUM，可应用TINYINT代替 解读： a）减少新的ENUM值要做DDL操作 b）ENUM的外部理论存储就是整数，你认为本人定义的是字符串？ 五、索引设计规范 **（19）单表索引倡议管制在5个以内** ...

云溪数据库delete语句delete from table where xxx的执行流程为： delete次要分为两个局部，一个局部为scan过程，拉取表中的数据，第二局部，依据过滤条件，调用b.Del()函数删除对应的数据。相干逻辑打算对象图为： deleteNode下蕴含一个scanNode，负责拉取表中数据，deleteRun包含理论执行delete操作的信息，包含表中数据的索引信息，事务相干信息txn，batch…，还有tabledesc等等信息。 其中在构建逻辑打算时，有一个maybeCreateDeleteFastNode函数，来判断是否能够执行deleterange操作，判断条件为： 1.表中是否具备索引，如果有，不能够执行deleterange 2.该表是否为交织表，如果是，不能够执行deleterange 3.该表主键是否关联了其余表的外键，如果是，不能够执行deleterange 4.renderNode下是否为scanNode，如果不是，不能够执行deleterange 5.过滤条件没有被下推为span，不能够执行deleterange 6.有limit关键字时，不能够执行deleterange 在满足以上过滤条件后，如果能够执行deleterange，就会把其中的deleteNode转化为deleteRangeNode，在执行时，rowCountNode的startExec会间接调用到deleteRangeNode的startExec，通过间接下发对span的DelRange操作来删除数据，不会调用到BatchNext中。 deleteRange过程局部代码: spans := make([]roachpb.Span, len(d.spans)) copy(spans, d.spans) for len(spans) != 0 { b := params.p.txn.NewBatch() for _, span := range spans { if traceKV { log.VEventf(ctx, 2, "DelRange %s - %s", span.Key, span.EndKey) } b.DelRange(span.Key, span.EndKey, true /* returnKeys */) } b.Header.MaxSpanRequestKeys = TableTruncateChunkSize if err := params.p.txn.Run(ctx, b); err != nil { return err } spans = spans[:0] for _, r := range b.Results { var prev []byte for _, keyBytes := range r.Keys { // If prefix is same, don't bother decoding key. if len(prev) > 0 && bytes.HasPrefix(keyBytes, prev) { continue } after, ok, err := d.fetcher.ReadIndexKey(keyBytes) if err != nil { return err } if !ok { return pgerror.NewAssertionErrorf("key did not match descriptor") } k := keyBytes[:len(keyBytes)-len(after)] if !bytes.Equal(k, prev) { prev = k d.rowCount++ } } if r.ResumeSpan != nil && r.ResumeSpan.Valid() { spans = append(spans, *r.ResumeSpan) } } }

问在 MySQL 运行时，咱们调整零碎工夫，会造成什么影响么？ 试验按常规，咱们造个数据库： 在一个会话里，进行vsleep： 在 sleep 的同时，咱们将服务器的工夫向将来调整 10 秒： 咱们会发现，sleep 立即退出，只执行了0.82 秒： 咱们在业务中很少会用到 sleep，那么调整零碎工夫会有更大的影响么？咱们再来看看： 咱们在一个会话中，锁住一张表： 在另一个会话中, 咱们做如下几件事: 先打印一个工夫戳调整 lock_wait_timeout拜访 test.a 表 此时, 咱们调整零碎工夫, 向过来调整 10 秒： 过一会，等拜访 test.a 的申请超时了，咱们来查看输入： 咱们将两个工夫戳相减，算出这个锁继续了多久： 5375908 - 5375891 = 17 秒 由此咱们晓得：调整零碎工夫，会影响 MDL 的等待时间的计算 小贴士 此处咱们获取零碎工夫的办法有点奇怪,是从 /proc/timer_list 中获取, 而并非应用date之类的函数 次要起因是: 当零碎工夫被调整, date等命令的输入也会受到影响. 咱们想主观的评估 MySQL理论期待了多久, 除了手动掐秒表, 还能够利用 枯燥时钟 (monotonic clock) 来进行计算. 枯燥时钟 不会受到零碎工夫变动的影响, /proc/timer_list中的输入就是枯燥时钟的一种 除了以上的试验, 调整零碎工夫, 对正在运行的MySQL还会有其余影响, 比如说 半同步的等待时间计算、 延时复制的延时工夫计算 等等 ...

上一篇咱们理解了什么是 MySQL 数据库。本文介绍如何在 Windows 平台应用 MySQL Installer 工具装置 MySQL 数据库服务器以及各种组件，以及 Linux 平台应用命令装置 MySQL 数据库服务器。 1.1 Windows 装置 MySQL1.1.1 下载 MySQL InstallerMySQL Installer 须要 Microsoft .NET Framework 4.5.2 或更高版本。对于初学者而言，在 Windows 平台上应用 MySQL installer 工具装置 MySQL 是最简略形式。它提供了十分直观的图形化向导模式，能够用于装置、降级、删除各种 MySQL 组件，包含： MySQL 服务器。MySQL 应用程序，包含 MySQL Workbench、MySQL Shell、MySQL Router、MySQL for Visual Studio、MySQL for Excel、MySQL Notifier 以及 MySQL 实用工具。MySQL 驱动程序，包含 MySQL Connector/NET、MySQL Connector/Python、MySQL Connector/ODBC、MySQL Connector/J、MySQL Connector/C 以及 MySQL Connector/C++。首先，咱们须要下载 MySQL Installer 的安装包。点击链接进入下载页面。 下载页面提供了两种安装文件（最新版本为 8.0.20）： ...

前言： 咱们晓得，数据库是存放数据的仓库。日常咱们应用数据库也是为了存储数据，和数据库打交道总免不了要进行数据导入工作。工作中也可能遇到各种不同的数据导入需要，本篇文章次要分享下数据导入相干的小技巧，心愿你能学到几招。 1.弄清需要是要害在进行数据导入前，咱们首先要分明想要做什么，要达到什么成果。最好也要分明导入的数据量有多大，这样对导入工夫也有个评估。 其次，对要导入的文件内容也要有大略理解，比方当初有一个 sql 脚本须要执行，那么你要先看下文件内容，是否存在建表语句、若原表存在该怎么解决、数据抵触又要怎么解决等等，这些都要有个预估。 2.几种数据导入场景上面咱们分场景来探讨下如何进行数据导入： 导入 sql 文件 这种场景还是比拟常见的，sql 文件中个别是 insert 语句。执行 sql 文件能够应用 mysql 命令行或 source 执行，例如：mysql -uroot -pxxx testdb < /tmp/testdb.sql ，应用 Navicat 等图形化工具也能够执行 sql 文件，这里倡议执行 sql 文件最好是通过命令行来执行，特地是比拟大的 sql 文件，应用命令行执行速度更快。 在导入 sql 文件前，要先进入数据库看下表信息，原表是否存在数据，如果是增量导入的话，自增 ID 最好不要指定，有惟一索引的字段要额定留神，如果是清空原表进行导入的话，最好当时进行备份下。 导入 Excel 或 CSV 文件 有时候咱们也须要将 Excel 表导入数据库中，绝对于 sql 文件，导入 Excel 文件显得更加简单些，因为 sql 文件中的 insert 语句是数据库能间接辨认的，而导入 Excel 文件则须要借助其余工具。 例如咱们能够借助 Navicat 的导入向导来导入 Excel 文件，首先要在数据库中创立对应的表，字段程序及类型要与数据相匹配，为了导入顺利，能够先不创立索引并容许字段为空。之后就能够借助导入向导抉择 Excel 文件进行导入了，如果首行是题目的话，记得疏忽首行。 不过，应用 Navicat 导入 Excel 文件只实用于数据量比拟小的状况，如果数据量比拟大且字段比较复杂的状况下，那就要进行革新解决了，比方能够应用 LOAD DATA 或者借助程序脚本进行解决后再导入。 ...

1.1 数据库数据库（Database）是许多相干数据形成的汇合。数据无处不在，数据库也是如此。例如，咱们手机上的联系人列表就是一个简略的数据库；咱们的银行账号就存储在银行数据库中；在网络上购物时，咱们浏览的是各种产品数据库，同时咱们的浏览和购买行为也被存储到电商后盾的用户行为数据库。 当用户或者利用须要拜访和应用这些数据库中的数据时，须要借助专门的治理软件系统，也就是数据库管理系统（DBMS）。依照数据的组织和管理模式，次要的 DBMS 能够分为关系数据库管理系统和非关系数据库管理系统。 关系数据库管理系统（RDBMS）次要应用二维表（Table）来存储数据，相似于 Excel 中的电子表格。表中的行对应一个实体或对象，列对应实体的属性。例如，公司的所有员工能够存储在员工表中，每行代表一个员工的信息，员工属性能够包含工号、姓名、性别、出生日期等。关系数据库应用规范的结构化查问语句（SQL）执行各种数据的增删改查以及数据库的治理操作。支流的关系数据库包含 MySQL、Oracle、SQL Server 以及 PostgreSQL 等。非关系数据管理系统（NoSQL）通常不反对关系模型，也不提供 SQL 接口。它们通常是为了解决关系数据库在某些场景下的局限性，例如大数据、横向可扩展性等。其中，NoSQL 代表 Not Only SQL。常见的 NoSQL 数据库包含键值存储（Redis 等）、文档数据库（MongoDB 等）、宽列存储数据库（Cassandra 等）以及图数据库（Neo4j 等）。1.2 MySQLMySQL 是最风行的开源关系数据库管理系统，由 Oracle 公司进行开发并提供反对。依据 CSDN 公布的《2019-2020 中国开发者调查报告》，83% 的开发者在应用 MySQL 数据库。 MySQL 最新版本为 MySQL 8.0，提供了大量的新性能，包含窗户函数（window function）和通用表表达式（Common Table Expressions）等。另外，MySQL 8.0 还提供了原生的文档数据库（JSON）反对，能够用于代替 MongoDB 这种文档数据库。MySQL 应用 GPL 开源协定，提供了收费的社区版；同时也提供免费的企业版本和技术支持。 MySQL 反对各种平台，包含 Windows、Linux 以及 macOS。绝对于其余大型的数据库系统（Oracle、SQL Server 等）而言，MySQL 更加容易治理和应用，同时又具备十分好的性能、可靠性和扩展性。 MySQL 能够反对客户端/服务器模式以及嵌入式的运行形式，非常适合开发网站或者 Web 利用；十分风行的 LAMP/LNMP 网站架构中的 M 就是指 MySQL。在国内，简直所有的支流和非主流互联网公司都会应用 MySQL 数据库。 ...

一、数据库根本设计规范数据库设计时，应该要对当前扩大进行思考所有表必须应用 InnoDB 存储引擎没有特殊要求（即 InnoDB 无奈满足的性能如：列存储，存储空间数据等）的状况下，所有表必须应用 InnoDB 存储引擎（MySQL 5.5 之前默认应用 Myisam，5.6 当前默认的为 InnoDB）InnoDB 反对事务，反对行级锁，更好的恢复性，高并发下性能更好。（==咱们程序中禁止应用事务，因为事务有锁表危险==）数据库和表的字符集对立应用 UTF8兼容性更好，对立字符集能够防止因为字符集转换产生的乱码，不同的字符集进行比拟前须要进行转换会造成索引生效。所有表和字段都须要增加正文应用 comment 从句增加表和列的备注 从一开始就进行数据字典的保护。尽量管制单表数据量的大小，倡议管制在 500 万以内500 万并不是 MySQL 数据库的限度，过大会造成批改表构造、备份、复原都会有很大的问题，能够用历史数据归档（利用于日志数据），分库分表（利用于业务数据）等伎俩来控制数据量大小。审慎应用 MySQL 分区表分区表在物理上体现为多个文件，在逻辑上体现为一个表 审慎抉择分区键，跨分区查问效率可能更低 倡议采纳物理分表的形式治理大数据。禁止在表中建设预留字段预留字段的命名很难做到见名识义 预留字段无奈确认存储的数据类型，所以无奈抉择适合的类型 对预留字段类型的批改，会对表进行锁定禁止在数据库中存储图片，文件等大的二进制数据通常文件很大，会短时间内造成数据量快速增长，数据库进行数据库读取时，通常会进行大量的随机 IO 操作，文件很大时，IO 操作很耗时 通常存储于文件服务器，数据库只存储文件地址信息。禁止在线上做数据库压力测试禁止从开发环境，测试环境间接连贯生成环境数据库二、数据库表设计规范设计表时，应该要对当前扩大进行思考所有表必须应用 InnoDB 存储引擎每张表必须有一个主键禁止应用外键束缚表的字符集对立应用 utf8mb4;排序应用utf8mb4_general_ci设计表时要加正文表前缀用项目名称字母缩写；所有表名都小写，单词之间用下划线离开，单词都用复数模式，命名要能做到见名识意，并且最好不要超过3 2 个字符关联表以_index 结尾长期库表必须以 tmp_ 为前缀并以日期为后缀备份表必须以 bak_ 为前缀并以日期 为后缀[^备份表]: bak_kyy_user_2021-11-01分表以_00～99结尾[^分表]: kyy_user_00、kyy_user_01三、数据库字段设计规范命名要能做到见名识意，单词之间用下划线离开字段要有明确的正文，形容该字段的用处及可能存储的内容禁止在表中建设预留字段。预留字段的命名很难做到见名识义 预留字段无奈确认存储的数据类型，所以无奈抉择适合的类型 对预留字段类型的批改，会对表进行锁定所有字段，均为非空（NOT NULL），最好显示指定默认值数值类型的字段请应用UNSIGNED属性是别的表的外键均应用xxx_id的形式来表明；所有的布尔值字段，以is_ 前缀，如is_hot、is_deleted，都必须设置一个默认值，并设为0；应用tinyint 类型varchar类型字段的程序处理，要验证用户输出，不要超出其预设的长度；不同表中表白同一意思字段要对立，例如创立工夫对立 用created_at;更新工夫用 updated_at;备注对立用 remark 排序对立用order_id防止应用ENUM 类型的 能够用tinyint 类型代替同财务相干的金额类型应用 decimal 类型text字段尽量少用，或是拆到冗余表中禁止给表中的每一列都建设独自的索引，正当应用联结索引，倡议索引数量不超过 5 个防止建设冗余索引和反复索引[^反复索引示例：]: primary key(id)、index(id)、unique index(id) [^冗余索引示例]: index(a,b,c)、index(a,b)、index(a)四、数据库操作标准禁止应用事务，有锁表危险不做非凡阐明，不做物理删除，对立做软删除防止数据类型的隐式转换（隐式转换会导致索引生效）尽量不应用 select * 倡议应用 select <字段列表> 查问禁止应用不蕴含字段列表的insert 语句禁止应用联表查问倡议应用 in 代替 or，in的值不要超过500个禁止应用 order by rand() 进行随机排序WHERE从句中禁止对列进行函数转换和计算什么时候应用组合索引，什么时候应用独自索引 以下是索引应用示例： ...

MySQL版本：8.0.27一、事务并发执行面临的问题1. 脏读（Dirty Read）如果事务A读到了未提交的事务B批改过的数据，就意味着产生了脏读景象。 2. 不可反复读（Non-Repeatable Read）如果事务B批改了未提交的事务A读取到的数据，就意味着产生了不可反复读景象。 3. 幻读（Phantom Read）事务A先依据某个范畴条件查问出了一些记录，而事务B写入了一些合乎该条件的新记录，当事务A再次以雷同的条件查问时，查问到了新的记录，就意味着产生了幻读景象。 二、SQL规范中的四种隔离级别1. READ UNCOMMITTED（未提交读）在 READ UNCOMMITTED 级别，事务中的批改，即便没有提交，对其余事务也都是可见的。也就是说该隔离级别会呈现脏读问题。 2. READ COMMITTED（已提交读）READ COMMITTED 解决了脏读问题，它满足事务隔离性的简略定义：一个事务从开始直到提交之前，所做的任何批改对其余事务都是不可见的。 3. REPEATABLE READ（可反复读）REPEATABLE READ 解决了脏读和不可反复读的问题。该级别保障了在同一个事务中屡次读取同样记录的后果是统一的。然而实践上，可反复读隔离级别还是无奈解决幻读（Phantom Read）问题。InnoDB 存储引擎通过 MVCC（多版本并发管制）和 Next-Key (临键锁) 很大水平上防止了幻读问题。可反复读是MySQL的默认事务隔离级别。 4. SERIALIZABLE（串行化）SERIALIZABLE 通过强制事务串行执行，防止了脏读、不可反复读和幻读的问题。SERIALIZABLE 会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用问题。 三、四种隔离级别比照隔离级别脏读可能性不可反复读可能性幻读可能性加锁读READ UNCOMMITTED√√√×READ COMMITTED×√√×REPEATABLE READ××√×SERIALIZABLE×××√四、四种隔离级别事务并行示例查看事务的隔离级别SHOW VARIABLES LIKE 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | REPEATABLE-READ |+-----------------------+-----------------+设置事务的隔离级别SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL <level>;level 有4个可选值： READ UNCOMMITTEDREAD COMMITTEDREPEATABLE READSERIALIZABLE批改全局隔离级别须要退出会话从新连贯MySQL失效。 初始数据CREATE TABLE `user` ( `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL COMMENT '姓名', `gender` char(1) NOT NULL COMMENT '性别', `age` tinyint(3) UNSIGNED NOT NULL COMMENT '年龄', `phone` char(11) NOT NULL COMMENT '电话', PRIMARY KEY (`id`) USING BTREE, INDEX `idx_username`(`name`) USING BTREE, UNIQUE INDEX `unq_phone`(`phone`) USING BTREE) ENGINE=InnoDB CHARACTER SET=utf8mb4;INSERT INTO `user` VALUES (10, 'M小明', '男', 16, '11111111111');INSERT INTO `user` VALUES (20, 'H小红', '女', 15, '22222222222');INSERT INTO `user` VALUES (30, 'L小丽', '女', 18, '33333333333');INSERT INTO `user` VALUES (40, 'M小梅', '女', 21, '44444444444');INSERT INTO `user` VALUES (50, 'L小亮', '男', 20, '55555555555');1. READ UNCOMMITTED（未提交读）SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;SHOW VARIABLES LIKE 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | READ-UNCOMMITTED |+-----------------------+-----------------+脏读事务A事务Bbegin;begin;SELECT * FROM user WHERE id=10;--UPDATE user SET age=11 WHERE id=10;SELECT * FROM user WHERE id=10; 读取到了事务B未提交的批改（age=11），呈现脏读--rollback;SELECT * FROM user WHERE id=10; 读取到的数据又变回了（age=10）-commit;-2. READ COMMITTED（已提交读）SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;SHOW VARIABLES LIKE 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | READ-COMMITTED |+-----------------------+-----------------+不可反复读事务A事务Bbegin;begin;SELECT * FROM user WHERE id=10;--UPDATE user SET age=12 WHERE id=10;SELECT * FROM user WHERE id=10; 读取不到事务B未提交的批改（age=10），没有呈现脏读--commit;SELECT * FROM user WHERE id=10; 读取到了事务B已提交的批改（age=12），呈现不可反复读-commit; 3. REPEATABLE READ（可反复读）SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;SHOW VARIABLES LIKE 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | REPEATABLE-READ |+-----------------------+-----------------+可反复读事务A事务Bbegin;begin;SELECT * FROM user WHERE id=10;--UPDATE user SET age=13 WHERE id=10;SELECT * FROM user WHERE id=10; 读取不到事务B未提交的批改（age=12），没有呈现脏读--commit;SELECT * FROM user WHERE id=10; 读取不到事务B已提交的批改（age=12），没有呈现不可反复读-commit; 幻读因为 MySQL 的 InnoDB 存储引擎通过 MVCC（多版本并发管制）和 Next-Key (临键锁) 很大水平上防止了幻读问题，所以无奈演示大部分幻读景象，然而InnoDB 存储引擎并不能齐全禁止幻读。 ...

I、基本概念事务保障一组数据库操作，要么全副胜利，要么全副失败。事务在引擎层实现（InnoDB反对，MyISAM不反对）。事务个性：原子性、一致性、隔离性、持久性。 个性体现原子性一个事务（transaction）中的所有操作，或者全副实现，或者全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。即，事务不可分割、不可约简。一致性在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设束缚、触发器、级联回滚等。隔离性数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含未提交读（Read uncommitted）、提交读（read committed）、可反复读（repeatable read）和串行化（Serializable）持久性事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。II、启动和回收1、长事务带来的问题—因为须要生成大量的undolog,所以占用大量的存储空间，其事务回滚工夫长—锁定数据过多，容易造成大量的死锁和锁超时2、怎么实现—显式启动事务语句，begin 或 start transaction。配套的提交语句是 commit，回滚语句是 rollback。—set autocommit=0。 START TRANSACTION 后，不论autocommit 是1还是0 。 只有当commit数据才会失效，ROLLBACK后就会回滚。 2、当autocommit 为 0 时，不论有没有START TRANSACTION。 只有当commit数据才会失效，ROLLBACK后就会回滚。 3、如果autocommit 为1 ，并且没有START TRANSACTION 。 会主动commit。调用ROLLBACK是没有用的。即使设置了SAVEPOINT。III、隔离级别1、解决什么问题：多事务并行时呈现的脏读（dirty read）、不可反复读（non-repeatable read）、幻读（phantom read）。 概念体现起因产生的隔离级别脏读读到其余事务未提交的数据当数据库中一个事务A正在批改一个数据然而还未提交或者回滚，另一个事务B 来读取了批改后的内容并且应用了，之后事务A提交了，此时就引起了脏读。读未提交不可反复读前后读取的记录内容不统一在一个事务A中屡次操作数据，在事务操作过程中(未最终提交)，事务B也才做了解决，并且该值产生了扭转，这时候就会导致A在事务操作的时候，发现数据与第一次不一样了，就是不可反复读。读未提交、读提交幻读前后读取的记录数量不统一一个事务按雷同的查问条件从新读取以前检索过的数据，却发现其余事务插入了满足其查问条件的新数据，这种景象就称为幻读。读未提交、读提交、可反复读2、隔离级别的定义（级别由低到高）： 定义体现了解 读未提交一个事务还没提交时，它做的变更就能被别的事务看到他人改数据的事务尚未提交，我在我的事务中也能读到读已提交一个事务提交之后，它做的变更才会被其余事务看到他人改数据的事务曾经提交，我在我的事务中能力读到可反复读一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的他人改数据的事务曾经提交，我在我的事务中也不去读串行对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行我的事务尚未提交，他人就别想改数据3、参数设置：transaction-isolation查问：show variables like 'transaction_isolation';4、怎么实现MVCC：多版本并发管制，通过undo log版本链和read-view实现事务隔离在 MySQL 中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都能够失去前一个状态的值。意思就是除了记录变更记录，还会记录一条变更相同的回滚操作记录，前者记录在redo log，后者记录在undo log。 IV、下一步须要理解的货色数据库视图undo log

不晓得为什么深秋的到来，让人变的有些许抑郁和不安 前言这篇应该算个小常识吧。平时习惯在写文章的时候都喜爱用 windows的emoji表情(win+.)即可弹出，就如♂️⛹️♂️♂️，还有、⛵，这种 之前开发的我的项目，没有存储过这种小表情，都是应用mysql的默认字符设置UTF-8,然而明天测试发现是行不通，而后就有了这篇小文章，心愿可能让你有所播种。 一、UTF-8 为什么不反对Emoji表情在一个utf-8表中所做测试，不反对插入数据中蕴含emoji表情的数据。 起因：MySQL数据库的 “utf8”并不是真正概念里的 UTF-8。目前可见字符集都只须要3个字节，蕴含了所有字符。然而问题出在unicode6系列编码上，它们须要4个字节，这部分就是有名的emoji。所以，如果咱们的数据库应用默认字符设置，是无奈存储emoji表情的。 二、UTF-8 与 UTF-8MB4 的区别2.1、UTF-8 （Unicode）咱们先谈谈UTF-8,最早只有127个字符被编码到计算机里，也就是大小写英文字母、数字和一些符号，这个编码表被称为ASCII编码，然而要解决中文显然一个字节是不够的，至多须要两个字节，而且还不能和ASCII编码抵触，所以，中国制订了GB2312编码，用来把中文编进去。你能够想得到的是，全世界有上百种语言，日本把日文编到Shift_JIS里，韩国把韩文编到Euc-kr里，各国有各国的规范，就会不可避免地呈现抵触，后果就是，在多语言混合的文本中，显示进去会有乱码。 因而，Unicode应运而生。Unicode把所有语言都对立到一套编码里，这样就不会再有乱码问题了。古代操作系统和大多数编程语言都间接反对Unicode。 所以在UTF-8编码中，一个英文字符占用一个字节的存储空间，一个中文（含繁体）占用三个字节的存储空间。 目前基本上可见字符集都只须要三个字节，蕴含了所有字符，然而目前问题出在了unicode6系列编码上，它们须要4个字节，这部分就是有名的emoji。所以，你只有不是特种编码还是unicode，且不存emoji，保障不出问题。 另外在此处，我有一点须要补充的是： MySQL数据库的 “utf8”并不是真正概念里的 UTF-8，起因下面是一点，还有一点是MySQL中的“utf8”编码只反对最大3字节每字符。真正的大家正在应用的UTF-8编码是应该能反对4字节每个字符。 但其实MYSQL的开发者，并没有润饰这个bug，而是推出了新的字符集，就是UTF-8MB4字符编码。如 2.2、UTF-8MB4UTF8MB4：MySQL在5.5.3之后减少了utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。因而能够用来存储emoji表情。 从8.0后，MySQL也将会在某个版本中开始应用UTF-8MB4作为默认的字符编码。 所以简略说即是：UTF-8MB4才是MySQL中真正的UTF-8编码。 那么如何让MySQL存储Emoji表情勒。 三、如何让MySQL存储Emoji表情咱们在创立数据库的时候，就须要选定utf-8mb4字符集，而不是utf-8。 咱们在设置字段字符集的时候，也须要设置为utf-8mb4字符集。 这样我在Navicat 中测试是能够的。 然而，我之前在网上查问相干材料的时候，说是须要批改一下my.ini配置文件， 在[mysqld]上面增加：character_set_server=utf8mb4，保留，重启mysql，应该就能够解决了。 ⌛四、喃喃自语留神：下次再有人问起设置什么样的编码，记得间接举荐设置utf-8mb4哦，这个才是MySQL真正的UTF-8编码哦。 开始想11月更文写什么，掘金大佬们，你说我当初开始学前端还有救吗。 大家也能够说说想看什么，我会就写写会，不会就去学学，给大家推推文。 咱们后端这阶段真的是处于一个是人是鬼都在卷的期间，困难重重啊。 大家好，我是博主宁在春：主页 一名喜爱文艺却踏上编程这条路线的小青年。 心愿：咱们，待别日相见时，都已有所成。 参考： Mysql中“utf-8”和"utf8mb4"的区别与应用场景 补充：发了这么多篇，终于有一个点赞了，开心一下

回顾，以最佳实际为终点作为一款 HTAP 数据库，TiDB 能同时解决来自用户端的 OLTP 在线业务与 OLAP 剖析业务。针对剖析类需要，优化器会主动将申请路由到列存的 TiFlash 节点；而对于在线申请，优化器会主动路由到行存 TiKV 申请。对于 HTAP 数据库，咱们最关怀的莫过于占用大量资源的剖析类查问是否会影响到在线的 OLTP 业务，针对这个问题，TiDB 在物理层上对 TiKV 与 TiFlash 进行了隔离，很好的防止了这种状况。 反思，最佳实际构造之痛通过资源隔离的形式，咱们解决了业务之间的相互影响。然而要想实现更灵便、高效的利用，下面的架构中依然存在肯定的问题： HAProxy 临时没有高可用性能对于 TiDB Server 来说，没有做到 TP 业务与 AP 业务的隔离对于以上的两个问题，咱们能够采纳以下的两种计划躲避下面的危险。 HAProxy 的高可用计划在生产环境中，个别咱们是不会独自应用 HaProxy 做 DNSRoundRobin 的。任何一个单点非高可用构造都会导致系统的不可用。HaProxy 自身是一个无状态的服务， 对于无状态服务，咱们能够通过多个服务来来躲避单节点的可用性危险。另外，在 HaProxy 之上，咱们能够通过 Keepalived 的探活脚本将 VIP 飘到一个可用的节点上，以实现单入口的高可用构造。 TP 与 AP 的隔离计划在 HTAP 场景中，咱们曾经通过将数据在物理层面上寄存在 TiKV 与 TiFlash 上来隔离 OLTP 和 OLAP 查问申请，真正实现了存储引擎级别的隔离。在计算引擎上，也能够通过 TiDB 实例级别设置 isolation-read 参数来实现 engine 的隔离。配置 isolation-read 变量来指定所有的查问均应用指定 engine 的正本，可选 engine 为 “TiKV”、“TiDB” 和 “TiFlash”（其中 “TiDB” 示意 TiDB 外部的内存表区，次要用于存储一些 TiDB 零碎表，用户不能被动应用）。 ...

从零开始学MYSQL - MYSQL装置前言 这个专栏也能够认为是学习笔记，因为之前的专栏学习的是网络上的培训机构教程，学习实现之后发现尽管讲到一些有一些深刻的货色，然而讲的都不是特地深，所以从这一节开始将会从零开始来全盘理解MYSQL，这里找了一本书《从根上了解Mysql》，集体也非常举荐读者去看看这边书，不仅有新个性对接解说，也有很多的干货，同时讲的也非常好，作为反对集体前面也买了一本实体书（尽管根本都是拿pdf看的）。 思维导图（继续更新）https://www.mubucm.com/doc/7D... 图片地址：https://gitee.com/lazyTimes/i... 参考资料：英文mysql5.7官网文档：https://dev.mysql.com/doc/ref...中文对应翻译网站（机翻）：https://www.docs4dev.com/docs...概述意识mysql的客户端和服务端是怎么一回事理解装置mysql的注意事项，以及回顾mysql集体简要介绍对于mysql启动的常见四个命令以及具体的作用 mysqldmysqld_safemysql.servermysqld_multi意识客户端和服务端 因为是Mysql的专栏，这里就不牵扯下面TCP/IP，什么网络传输协定了，总之咱们只须要理解mysql是分为客户端和服务端的，通常咱们拜访页面或者浏览数据就是一次数据库的拜访过程（当然当初少数货色都动态化了），所以连贯的这一方被称为客户端而承受申请的这一方面被称为服务端。 mysql的根本工作通常咱们应用MYSQL根本都是干这些事件： 连贯数据库。查询数据库的数据，客户端发送申请给服务端，服务端依据命令找到数据回送给客户端。和数据库断开连接。mysql实例 说完了下面的废话之后，咱们来说下mysql实例，实例也在操作系统的层面叫做过程，而过程能够看做是处理器，内存，IO设施的形象，咱们不须要晓得这个过程底层是如何传输数据存储数据的，咱们只须要理解他须要一个端口，并且每一个实例都有一个 过程ID的货色，在数据库实例运行的时候零碎会调配一个过程ID给它并且保障惟一，而每一个过程都有本人的名字，这个名称是装置的时候由程序员本人设置的，然而如果没有调配则会应用MYSQL本人默认设置的名称。 咱们启动的 MySQL 服务器过程的默认名称为 mysqld ， 而咱们罕用的 MySQL 客户端过程的默认名称为 mysql 。 从这个名称咱们也能够揣测出为什么咱们启动一个服务通常会应用Mysqld，而咱们连贯数据库通常应用mysql。 每一个文件就是对于IO设施的形象虚拟内存是对内存和IO设施的形象过程：则是对处理器，虚拟内存和IO设施的形象装置Mysql的注意事项 装置Mysql其实是一件非常简略然而实际上如果全手动装置细节还是比拟多的，通常状况下咱们本人应用间接用EXE程序或者间接应用BIN包等，但很多时候对于Linux的软件很多人都会举荐应用 源码装置，源码装置的益处不仅仅是放大体积，通过不少的试验证实源码的装置形式效率会有所晋升，所以正式环境下 尽可能应用源码装置，最初须要留神的一点是：Linux下应用RPM包会有独自的服务器和客户端RPM包，须要别离装置。 装置目录地位的区别 上面是具体的Mysql装置目录，当然上面这里只做参考，集体mac电脑应用的是brew install mysql加上m1的的芯片装置的，适配性未知，所以为了保障笔记的牢靠，这里用回了windows零碎来进行理论测试和演练，上面是不同的操作系统在mysql的装置目录存储地位存在轻微的不同，然而肯定要非常分明mysql实在的装置地位，这对于本人捣鼓各种命令以及设置参数很重要。 macOS 操作系统上的装置目录：/usr/local/mysql/Windows 操作系统上的装置目录：C:\Program Files\MySQL\MySQL Server 5.7Mysql装置windows装置过程 装置过程就不演示了，网上的教程一抓一大把，为了稳当起见这里集体应用的mysql版本是5.7的版本，同时应用了默认exe程序安装，如果你应用了mysql-installxx.exe装置，有的时候会呈现上面的命令： 'mysql' 不是外部或外部命令，也不是可运行的程序 看到这个提醒之后，第一反馈是进入power shell的管理员模式： PS C:\Windows\system32> mysql -uroot -pmysql : 无奈将“mysql”项辨认为 cmdlet、函数、脚本文件或可运行程序的名称。请查看名称的拼写，如果包含门路，请确保门路正确，而后再试一次。所在位置 行:1 字符: 1+ mysql -uroot -p+ ~~~~~ + CategoryInfo : ObjectNotFound: (mysql:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException 发现还是报错，而后我跑去服务看了下mysql是否有启动，发现mysql又是启动的，这里有点奇怪。 ...

官网对索引（index）的定义是：索引是一种帮忙mysql疾速查找获取数据的数据结构，所以索引的实质是一种数据结构。 索引的劣势：疾速获取数据，升高IO老本索引的劣势：索引也须要占用内存，插入，更新会导致索引结构调整，所以尽管进步了查问速度，然而插入数据和更新数据变慢。 索引的分类：从数据结构上来说：索引分为hash索引，B+Tree索引，全文索引，R-Tree索引从物理角度来说：索引分为聚簇索引，非聚簇索引从逻辑角度来说：索引分为主键索引，一般索引，多列索引，惟一索引，空间索引 注：1.联结索引只会创立一个索引（一颗索引树），比方联结索引（a,b,c）,然而成果相当于创立了a,ab,abc 留神最左匹配准则2.回表查问就是通过一般索引找不到须要的数据，须要借助主键去获取，能够通过笼罩索引解决回表查问

Explain 介绍为了优化MySQL的SQL语句的执行性能，MySQL提供了explain关键字用于查看SQL的执行打算。格局如下： {EXPLAIN | DESCRIBE | DESC} tbl_name [col_name | wild]{EXPLAIN | DESCRIBE | DESC} [explain_type] {explainable_stmt | FOR CONNECTION connection_id}explain_type: { EXTENDED | PARTITIONS | FORMAT = format_name}format_name: { TRADITIONAL | JSON}explainable_stmt: { SELECT statement | DELETE statement | INSERT statement | REPLACE statement | UPDATE statement}DESCRIBE和EXPLAIN语句是同义词。实际上，DESCRIBE关键字更罕用于获取无关表构造的信息，而EXPLAIN用于获取查问执行打算（即，解释MySQL将如何执行查问）。 从下面的EXPLAIN的用法能够看出： EXPLAIN 能够与 SELECT, DELETE, INSERT, REPLACE 和 UPDATE 一起应用，用于查问相应SQL的执行打算。当EXPLAIN与可解释语句(explainable statement)一起应用时，MySQL显示来自优化器的对于语句执行打算的信息。也就是说，MySQL解释了它将如何解决该语句，包含无关如何联接表以及以何种程序联接表的信息。当EXPLAIN与FOR CONNECTION connect_id 而不是可解释语句一起应用时，它将显示在命名连贯中执行的语句的执行打算。对于SELECT语句，EXPLAIN能够应用SHOW WARNINGS 语句显示的其余额定的执行打算信息。EXPLAIN对于查看波及分区表的查问很有用。FORMAT选项可用于抉择输入格局。TRADITIONAL以表格格局显示输入,默认为TRADITIONAL，JSON格局以JSON格局显示信息。在EXPLAIN的帮忙下，能够看到应该在哪里向表增加索引，以便通过应用索引查找使语句执行得更快，还能够应用EXPLAIN查看优化器是否以最佳程序连贯表。 当EXPLAIN与SELECT语句一起应用时，EXPLAIN的后果以表格的格局显示输入，每个行示意一张表。MYSQL应用循环内嵌的办法解析所有的表的连贯，也就意味着MYSQL会先读取第一张表的第一行，而后在第二张表中查找匹配的行，而后是第三张表等。当所有的表格都解决实现之后，MySQL输入所选列并回溯所有表，直到找到一个表，其中有更多匹配行。从该表中读取下一行，并持续解决下一个表。 Explain 的输入EXPLAIN中的每个输入行提供对于一个表的信息。EXPLAIN的输入如下(第二列为FORMAT=JSON时的输入)： ColumnJSON NameMeaningidselect_idThe SELECT identifierselect_typeNoneThe SELECT typetabletable_nameThe table for the output rowpartitionspartitionsThe matching partitionstypeaccess_typeThe join typepossible_keyspossible_keysThe possible indexes to choosekeykeyThe index actually chosenkey_lenkey_lengthThe length of the chosen keyrefrefThe columns compared to the indexrowsrowsEstimate of rows to be examinedfilteredfilteredPercentage of rows filtered by table conditionExtraNoneAdditional information上面对下面的每一列逐个阐明：id ： 这是查问中SELECT的序列号。如果该行指的是其余行的UNION后果，则该值能够为NULL。在这种状况下，table 列显示一个相似<unionM，N>的值，以批示该行援用id值为M和N的行的并集。 ...

小弟新写了一个性能，自测和测试环境测试都没问题，但在生产环境会呈现偶发问题。于是，加班到12点始终排查问题，终于定位了的问题起因：Mysql Limit查问优化导致。现形象出问题模型及解决方案，剖析给大家，防止大家踩坑。 问题场景新上线一个交易记录导出性能，逻辑很简略：依据查问条件，导出对应的数据。因为数据量比拟大，在查询数据库时采纳了分页查问，每次查问1000条数据。 自测失常，测试环境失常，上线之后经营反馈导出的数据有重复记录。 本来是认为业务逻辑问题，从新Review了一遍代码，仍旧未找到问题起因。最初只好把SQL语句拿进去独自执行，导出数据，比照发现居然是SQL语句查问后果乱序导致的。 起因剖析查问语句以create_time进行倒序排序，通过limit进行分页，在失常状况下不会呈现问题。但当业务并发量比拟大，导致create_time存在大量雷同值时，再基于limit进行分页，就会呈现乱序问题。 呈现的场景是：以create_time排序，当create_time存在雷同值，通过limit分页，导致分页数据乱序。 比方，查问1000条数据，其中有一批create_time记录值都为”2021-10-28 12:12:12“，当创立工夫雷同的这些数据，一部分呈现在第一页，一部分呈现在第二页，在查问第二页的数据时，可能会呈现第一页曾经查过的数据。 也就是说，数据会来回跳动，一会儿呈现在第一页，一会儿呈现在第二页，这就导致导出的数据一部分反复，一部分缺失。 查看了Mysql 5.7和8.0的官网文档，形容如下： If multiple rows have identical values in the ORDER BY columns, the server is free to return those rows in any order, and may do so differently depending on the overall execution plan. In other words, the sort order of those rows is nondeterministic with respect to the nonordered columns.上述内容概述：在应用ORDER BY对列进行排序时，如果对应（ORDER BY的列）列存在多行雷同数据，（Mysql）服务器会依照任意程序返回这些行，并且可能会依据整体执行打算以不同的形式返回。 简略来说就是：ORDER BY查问的数据，如果ORDER BY列存在多行雷同数据，Mysql会随机返回。这就会导致尽管应用了排序，但也会产生乱序的情况。 解决方案针对上述问题，根本的解决思路是：防止ORDER BY列的值呈现反复。因而，能够退出其余维度，比方ID等其余排序列。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景某天有人问了我一个无关 MySQL PROXY 用户该如何应用的问题。 原问题是这样的：MySQL 版本从 5.5 降级到 8.0 后，proxy 用户怎么无奈应用了？我之前是依照你博客上写的办法应用的，然而在降级后，装置插件提醒如下谬误： mysql:(none)>install plugin test_plugin_server soname 'auth_test_plugin.so';ERROR 1126 (HY000): Can't open shared library 'auth_test_plugin.so' (errno: 0 API version for AUTHENTICATION plugin is too different)这个咋回事？ 我给了一个大家都很厌恶的答案： 去看 MySQL8.0 官网手册吧。 注释其实MySQL版本倒退到8.0，曾经齐全没有必要应用 proxy 用户这个性能了，能够用角色完满代替。auth_test_plugin.so 是 MySQL 5.5 的插件，仅限于测试环境，不举荐线上应用，仅限性能演示。之后的一系列大版本安装包里都不蕴含这个插件，所以应用办法有些差别。 上面我对 proxy 用户在 MySQL 8.0 下如何应用做下简略演示。我在上面示例中应用插件 mysql_native_password ，这个插件自带 proxy 用户性能，所以须要在配置文件里开启对应的开关，并重启 MySQL 实例：（如果应用 sha256_password ， 应该把参数 sha256_password_proxy_users=ON 也加到配置文件里。） ...

分表的目标我的项目开发中，咱们的数据库数据越来越大，随之而来的是单个表中数据太多。以至于查问数据变慢，而且因为表的锁机制导致利用操作也受到重大影响，呈现了数据库性能瓶颈。 当呈现这种状况时，咱们能够思考分表，行将单个数据库表进行拆分，拆分成多个数据表，而后用户拜访的时候，依据肯定的算法，让用户拜访不同的表，这样数据扩散到多个数据表中，缩小了单个数据表的拜访压力。晋升了数据库拜访性能。 举个栗子 比方咱们最常见的用户表（user表） iduser_id其余字段主键id用户id其余字段咱们个别都会用user_id去查问对应的用户信息，然而随着业务的增长，这张表会越来越大，甚至上亿，重大影响了查问性能。所以咱们就会对这张表进行分表处理，分到多张表减小查问压力 分表策略以分10张表为例(具体分多少张表 依据理论状况来估算)首先咱们建10张表 user1、user2、user3。。。。。user10 个别状况下，咱们都会用作为索引的字段(user_id)进行取模解决。想分多少张表，就依照多少取模，比方这个case就是10 $table_name = $user_id % 10;依照下面的取模公式 user_id为1295的会落在user5外面user_id为8634的会落在user4外面。。。。。。。每次CURD依据下面查找表的策略进行就行了，这个问题不大，咱们暂且先不多说。 曾经上线的运行中的表怎么办？其实下面的办法大家应该都晓得怎么用，然而有个问题，曾经上线了的表怎么办？那张表的数据在线上是始终被查找或者扭转的。如何可能进行平滑的分表，并且让用户无感知呢？ 办法1间接上线，提前写个脚本，脚本内容是把旧表(user)的数据同步到user1表到user10表，一上线了连忙执行 这种办法显著是行不通的，次要是存在以下问题 如果执行过程中脚本有问题怎么办？代码全副回滚？脚本把把旧表(user)的数据同步到user1表到user10表，这个脚本得执行多久？ 如果是1个小时，那么这段时间线上和这张表相干的业务都是不失常的这显然是行不通的，对线上影响很大。 办法2先写个同步数据的脚本，脚本内容是把旧表(user)的数据同步到user1表到user10表，脚本同步完了再上线。 这个办法看起来敌对了一些，不过也存在一些问题。 脚本同步完，立刻上线，这两件事之间是有一些时间差的，这个时间差中线上表可能有一些改变，这些改变怎么办？以上两种办法看起来貌似都行不通，所以看来得来点不一样的了。咱们间接看论断。 步骤1 上线双写首先咱们把双写上线了，什么意思呢？比方user_id=123，对于减少，删除，批改操作来说，咱们既操作user表，也操作user_id=123对应的user3表。 function modify($user_id){ //蕴含减少，删除，批改操作 modify_user(); //modify user表 $table_name = $user_id % 10; modify_user($table_name) //modify对应的分表}因为查问的局部还是在user表中查问的，所以下面的操作对线上用户是无任何影响的。 步骤2 全量同步写一个全量同步user表到user1-user10的表，最好找个低峰期执行脚本，以防万一影响user表的查问 这一步执行之后，因为咱们之前上线了双写(见步骤1)，所以user表和user1-user10表之间的数据曾经是完全一致的了。 步骤3 查问新表数据将查问的局部改到user1-user10 因为后面两个步骤咱们曾经保障了user表和各个分表之间的数据齐全一致性，所以间接把查问的局部改掉是没有任何问题的 如果依照以上步骤执行，那么对线上的数据是没有任何影响的，而且咱们线上就是这么操作了，通过了屡次实际确保不会出问题，放心使用即可。如果这篇文章帮忙到了你，记得点个赞哦。

binlog记录MySQL的所有批改操作，包含DML操作(create/update/delete)以及DDL操作，必须是已提交的事务。 binlog能够在从库中进行重放，以实现MySQL数据的高可用: master节点将数据批改操作写入本机的binlog；slave节点上的I/O线程读取master节点的binlog，并写入到本地的relay-log；slave节点上的SQL线程读取relay-log并进行重放； binlog格局有：statement、row、mixed； > show variables like 'binlog_format';+---------------+-------+| Variable_name | Value |+---------------+-------+| binlog_format | ROW |+---------------+-------+1 row in set (0.001 sec)statement格局statement记录的是执行的sql语句，也就是主库上执行了什么语句，binlog中就记录什么语句。 statement格局的长处： 因为仅记录sql语句，日志记录量较少，能够节约磁盘和网络I/O；statement格局的毛病： 对于特定的函数，比方UUID()，user()这些非确定性函数，在主备服务器上的执行后果不同，可能造成主备数据不统一；生产环境中个别不应用。statement格局的问题statement格局可能导致主备服务器数据的不统一，比方下表t: mysql> CREATE TABLE `t` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `t_modified`(`t_modified`)) ENGINE=InnoDB;insert into t values(1,1,'2018-11-13');insert into t values(2,2,'2018-11-12');insert into t values(3,3,'2018-11-11');insert into t values(4,4,'2018-11-10');insert into t values(5,5,'2018-11-09');当执行sql语句： mysql> delete from t where a>=4 and t_modified<='2018-11-10' limit 1;设置binlog_format=statement，如果主库和从库上在执行上述sql语句时，抉择了不同的索引，则会删除不同的数据： ...

一，按业务维度拆分比方一个零碎可能蕴含了用户，商品，订单业务，因为这三个维度在拜访与数据读写上不均衡，为防止相互影响，进步性能，能够按业务维度拆分成用户零碎，商品零碎与订单零碎。 二，数据归档针对有的数据只须要留存而不波及到读写，能够思考将其归档。像肯定工夫前的拜访日志 三，读写拆散对于某个零碎来说，当其倒退到肯定阶段，数据库必然会成为瓶颈，能够先思考实现读写拆散以加重对主库的压力，实现的形式大抵有两种： 中间件路由。在利用与数据库之间，由中间件将申请转发到读库或写库。相干的中间件有：Amoeba，MySQL-Proxy，MaxScale，MyCat等。利用外部实现路由。利用与数据库直连，由利用来定应用读库或写库。相干技术有spring 动静数据源,Sharding-JDBC等。应用中间件的长处是对业务通明，不必批改代码，毛病是加长了调用链路，减少了故障点、升高了性能；而在利用外部进行路由则相同。另外实现了读写拆散须要思考上面几个问题： 故障转移的问题。相干的技术有MHA，keepalive，MyCat等。如果是应用利用进行的路由，则须要在利用里配置读写数据源。主从提早的问题。针对这个问题一方面看能不能从业务上躲避，如果躲避不了则有针对性的将相干读服务连主库。另一方面如果读性能瓶颈很大，能够间接思考应用缓存代替，用缓存分片来应答数据量大的问题。四，分表分库数据量大到肯定水平后，数据库的读写性能会降落，更别说那些较简单的查问，个别业说单表数据达到千万级别就算是量很大，须要思考拆分存储了。就单库而言，并发达到2000曾经算是性能很不错了，如果再大就防止不了分库。简略一句：数据量大，就分表；并发高，就分库。 4.1分片策略范畴分片优：减少或缩小分片时根本不波及数据迁徙，扩展性强劣：易呈现热点数据HASH分片优：数据分布平均劣：减少或缩小分片时波及数据迁徙，不利扩大查表法优：能够较灵便的制订映射算法，扩展性较强劣：映射表可能成为热点表，能够思考加缓存4.2分片须要思考的问题sharding key的抉择如何确定分片键的时候须要依据业务来定，能够在多个维度将分片键与其它常用字段进行冗余存储。分布式事务分布式主键ID能够思考应用全局生成主键表，雪花算法等。跨库JOIN，翻页等罕用的做法是将全量数据存入es或应用hive；进行数据冗余；借助中间件；是否从业务上限度。

10 月 18 日~ 20 日，第 12 届中国数据库技术大会（DTCC2021）在北京国际会议中心隆重召开。PingCAP 联结创始人兼 CTO 黄东旭受邀在主会场进行了以“TiDB Cloud：from Product to Platform” 为主题的演讲，分享了云原生时代数据库产品平台化的重要性，以及 TiDB 从 DB 到 DBaaS 的教训和领会。以下为分享实录。 在最近数据库行业的倒退中，比起 “代码写得好不好” 这样的工程技术问题，迷信问题更加突出：有一件事件十分粗浅地扭转了整个数据库的行业，那就是数据库底层产生了变动。以往大家去思考数据库软件和系统软件，都会先做一个假如：软件是跑在计算机等具体的硬件上的，即便是分布式数据库，每个节点都还是一个一般的计算机。当初这个假如扭转了：咱们的下一代到可能学编程或者写代码的年纪，不会再像咱们当初这样可能看到 CPU、硬盘、网络，他们看到的可能就是 AWS 提供的一个 S3 的 API 。其实这种扭转并不仅是软件载体的扭转，更重要的是架构、编程的底层逻辑产生了变动。云对基础设施和软件的影响和扭转是深远的。具体到 PingCAP 身上，最大的感触就是比起做数据库内核， 当初在云上做 TiDB Cloud 服务的投入可能多得多。这也是我明天要分享的主题，From Product to Platform —— 从 DB 到 DBaaS，数据库技术的以后和将来。 PingCAP 的守业初心上图是我了解的数据库倒退历程。追溯到十几年前，咱们开始应用单机 MySQL，这个期间咱们对数据库的需要只有奢侈的增删改查，2010 年前后直到明天，暴发的数据量让单机数据库难以为继，大家只能通过分库分表或者中间件来实现分布式部署。 然而分库分表对业务的入侵性太大，那能不能有这样一个数据库，用起来和单机 MySQL 一样简略，然而扩容时不须要思考分片，而是通过零碎自身的机制来实现弹性、舒服、业务无入侵的拓展？这就是 PingCAP 守业的初心。PingCAP 守业六年多以来，为了达成这个小指标，也总结了几点心得： 易用优先：协定大于实现MySQL 协定比 MySQL 具体软件更重要。如果一款数据库可能兼容 MySQL 协定，能让用户在数据库的选型过程中无需思考对利用和业务的影响，就能领有最大的用户群。咱们无需创造一种新的应用形式，就像电动车还是会通过方向盘和油门来操控，尽管引擎下的世界和汽油车齐全不同。 用户体验优先数据库的性能指标比方 TPS、QPS 等诚然重要，然而用户的体验才是一款数据库胜利的要害。因而，TiDB 在做所有技术决策的时候都是通过用户体验（Usability matters）来判断。从我过来的教训来看，许多互联网公司须要保护的数据库品种十分多，每启用一种新的数据库就会多一个数据孤岛。因而，在满足用户数据处理需要的同时，简化的技术栈可能才是真正的用户痛点。无论是 OLTP、OLAP 还是 HTAP，TiDB 心愿做的事就是让大家的生存变得好一点。 ...

I、MySQL根本逻辑架构 分层组件性能server层连接器、查问缓存、分析器、优化器、执行器、内置函数等存储过程、触发器、视图存储引擎层InnoDB、MyISAM、Memory等（默认InnoDB）数据的存储和提取注：建表时应用参数engine=$engine指定存储引擎； server为所有类型的存储引擎共用。II、一条SQL语句如何执行 III、redo log和binlogredo logredo logbinlog参数innodb_flush_log_at_trx_commit=1sync_binlog=1作用crash-safe归档分层引擎特有server层共有反对引擎InnoDB不辨别引擎日志级别物理日志逻辑日志写入形式循环写追加写存储占有固定不固定注：redo log的过程与《孔乙己》掌柜记账形象化类比了解IV、两阶段提交1、两阶段提交：redo log的写入拆成了两个步骤：prepare和commit。2、利用场景：数据库复原和扩容。3、目标：怎么让数据库复原到半个月内任意一秒的状态？4、如果不应用两阶段提交：数据库的状态就有可能和用它的日志复原进去的库的状态不统一。

慢查问的环境变量slow_query_log: 是否启用慢查问日志，ON=启用，OFF=禁用；slow_query_log_file: 慢查问日志的寄存文件； > show variables like '%slow_query%';+---------------------+-----------------+| Variable_name | Value |+---------------------+-----------------+| slow_query_log | ON || slow_query_log_file | armpvm-slow.log |+---------------------+-----------------+2 rows in set (0.001 sec)long_query_time: 慢查问的工夫阈值，单位s； > show variables like '%long_query%';+-----------------+----------+| Variable_name | Value |+-----------------+----------+| long_query_time | 1.000000 |+-----------------+----------+1 row in set (0.001 sec)log_queries_not_using_indexes：是否记录未应用索引的sql语句，记录=ON，不记录=OFF； > show variables like '%log_queries%';+-------------------------------+-------+| Variable_name | Value |+-------------------------------+-------+| log_queries_not_using_indexes | OFF |+-------------------------------+-------+1 row in set (0.001 sec)慢查问日志的统计分析应用mysqldumpslow工具进行慢查问的统计分析： # mysqldumpslow --helpParse and summarize the MySQL slow query log. Options are --verbose verbose --debug debug --help write this text to standard output -v verbose -d debug -s ORDER what to sort by (aa, ae, al, ar, at, a, c, e, l, r, t), 'at' is default aa: average rows affected ae: aggregated rows examined al: average lock time ar: average rows sent at: average query time a: rows affected c: count e: rows examined l: lock time r: rows sent t: query time -r reverse the sort order (largest last instead of first) -t NUM just show the top n queries -a don't abstract all numbers to N and strings to 'S' -n NUM abstract numbers with at least n digits within names -g PATTERN grep: only consider stmts that include this string -h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard), default is '*', i.e. match all -i NAME name of server instance (if using mysql.server startup script) -l don't subtract lock time from total time按执行总工夫，统计top 10的sql语句： ...

binlog复制模式异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立刻将后果返回给客户端，并不关怀从库是否曾经接管并解决。 这样就会有一个问题，如果主库crash掉了，此时主库上曾经提交的事务可能并没有传到从库上，如果此时强行将从库晋升为主库，可能导致新主库上的数据不残缺。 全同步复制（Fully synchronous replication） 当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。 因为须要期待所有从库执行完该事务能力返回，所以全同步复制的性能必然会受到重大的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立即返回给客户端，而是期待至多一个从库接管并且写到relay log中才返回给客户端。 绝对于异步复制，半同步复制进步了数据的安全性，同时它也造成了肯定水平的提早，这个提早起码是一个TCP/IP往返的工夫。所以，半同步复制最好在低延时的网络中应用。 半同步复制半同步复制有AFTER_COMMIT和AFTER_SYNC两种形式。 AFTER_COMMIT同步过程： 用户向master提交事务；master节点处理事务，写binlog，commit该事务；master节点期待slave将binlog写入relay-log；master节点返回client事务执行后果； AFTER_COMMIT的问题若事务在master节点commit后，在期待slave节点的确认过程中，master节点宕机了，此时有两种状况：1.事务还未发送到从库此时client收到事务失败的后果，client会从新提交事务到新master上。当宕机的老master重新启动后，以slave的角色退出后，该事务将从新master上同步过去，导致被再次提交一次。 2.事务已发送到从库此时slave曾经收到binlog并利用了该事务，当client因为事务失败而再次提交时，该事务被从新提交到新master上。 AFTER_SYNC同步过程： 用户向master提交事务；master节点执行事务，写binlog；master节点期待slave将binlog写入relay-log；master节点commit该事务；master节点向client返回事务执行后果； 半同步复制参数MariaDB [(none)]> show variables like '%semi%';+---------------------------------------+--------------+| Variable_name | Value |+---------------------------------------+--------------+| rpl_semi_sync_master_enabled | OFF || rpl_semi_sync_master_timeout | 10000 || rpl_semi_sync_master_trace_level | 32 || rpl_semi_sync_master_wait_no_slave | ON || rpl_semi_sync_master_wait_point | AFTER_COMMIT || rpl_semi_sync_slave_delay_master | OFF || rpl_semi_sync_slave_enabled | OFF || rpl_semi_sync_slave_kill_conn_timeout | 5 || rpl_semi_sync_slave_trace_level | 32 |+---------------------------------------+--------------+rpl_semi_sync_master_enabled：master是否启用半同步rpl_semi_sync_slave_enabled：slave是否启用半同步rpl_semi_sync_master_timeout：master期待slave写入relay-log的超时工夫，默认10s；

前言对于联结索引的考察点，面试中常见的问题大略有这几个，然而重点必定扯一些最左匹配准则，问一下本人是否可能答上对于联结索引相干的嘛。 什么是联结索引联结索引的查找过程什么是最左前缀法令建设联结索引的时候为什么有的时候索引会生效索引下推过程形容联结索引是什么 基于多个字段创立的索引咱们称为联结索引，比方咱们创立索引create index idx on table(A,B,C) 咱们称在字段A,B,C上创立了一个联结索引 存储构造 在上篇文章中，咱们晓得，索引存储底层是B+树，在InnoDB存储引擎下，主键索引叶子节点存储的是数据，非主键索引上存储的是主键id，在联结索引下，这个B+树是如何组织的呢，咱们通过一个具体的例子来看一下，首先咱们先建设一个表，向表里增加一些数据。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id自增', `age` int(11) NULL DEFAULT NULL COMMENT '年龄', `money` int(11) NULL DEFAULT NULL COMMENT '账户余额 ,真正开发时候，余额不能用整数哈', `ismale` int(11) NULL DEFAULT NULL comment '性别 0男1女', `name` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL comment '名称', PRIMARY KEY (`id`) USING BTREE, INDEX `index_bcd`(`age`, `money`) USING BTREE) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic; ...

聚簇索引是指索引的构造跟数据记录的物理存储构造统一，也能够说，聚合索引就是数据记录的物理存储构造，innodb引擎中，聚簇索引就是主键索引。 以表t为例，剖析在不同存储引擎下，其索引的构造： create table t( id int primary key auto_increment, score int, name varchar(255), KEY idx_name (name));Innodb引擎主键索引(聚簇索引)主键索引即聚簇索引，叶子节点存储残缺的一条记录，非叶子节点存储索引字段的值。 聚簇索引的问题：记录插入查问依赖主键的程序。若按主键有序插入，那么主键索引是程序写入，性能较高；若主键不是有序插入，比方uuid，则每次插入需查找插入地位(可能还波及页决裂)，变成随机写入，性能较差； 非主键索引非主键索引，也称为二级索引，叶子节点存储主键的ID，若要查问记录的其它信息，则须要回表到主键索引。 MyISAM引擎MyISAM引擎依照记录的插入程序，保留到磁盘上。 MyISAM的主键索引和非主键索引均不是聚簇索引，都不同于记录的物理存储构造。 主键索引主键索引，其叶子节点存储该条记录的地址。 非主键索引非主键索引，同主键索引相似，叶子节点存储该条记录的地址。

如何在 MySQL 数据库治理中，查询数据库、表、索引的容量大小？咱们能够在 MySQL 自带的 information_schema 库中的 Table 表里，找到所需信息。 在每个 MySQL 实例中，都有一个独立的 information_schema 库，它是自带的默认库，记录着这个 MySQL 实例中所有数据库的元数据、统计信息、以及无关 MySQL 的拜访权限信息。这其中就包含了所有数据库、表、索引的详细信息。 如果你想应用图形工具构建本人的「数据库容量看板」并且一键分享给小伙伴共享看板，可在本文文末，找到如何应用卡拉云 1 分钟搭建「数据库容量看板」的教程。 本教程所用到的 information_schema 库中 Table 表里的字段： TABLE_SCHEMA : 数据库名TABLE_NAME：表名ENGINE：所应用的存储引擎TABLES_ROWS：记录数DATA_LENGTH：数据容量大小INDEX_LENGTH：索引容量大小 更多无关 information_schema 的信息，大家可在查看 MySQL 手册 深刻理解。 无关 information_schema.TABLES 更多字段信息，能够应用以下命令查看更多： use information_schemaSHOW COLUMNS FROM TABLES; 查看 MySQL「所有库」的容量大小SELECT table_schema as '数据库',sum(table_rows) as '记录数',sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)',sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)',sum(truncate(DATA_FREE/1024/1024, 2)) as '碎片占用(MB)'from information_schema.tablesgroup by table_schemaorder by sum(data_length) desc, sum(index_length) desc;特地提醒：data_length 、index_length 等字段，所存储的容量信息单位是字节，所以咱们要除以 2 个 1024 把字节转化为可读性更强的 MB，下文同理，不再累述。 ...

如何在 MySQL 数据库治理中，查询数据库、表、索引的容量大小？咱们能够在 MySQL 自带的 information_schema 库中的 Table 表里，找到所需信息。 在每个 MySQL 实例中，都有一个独立的 information_schema 库，它是自带的默认库，记录着这个 MySQL 实例中所有数据库的元数据、统计信息、以及无关 MySQL 的拜访权限信息。这其中就包含了所有数据库、表、索引的详细信息。 如果你想应用图形工具构建本人的「数据库容量看板」并且一键分享给小伙伴共享看板，可在本文文末，找到如何应用卡拉云 1 分钟搭建「数据库容量看板」的教程。 本教程所用到的 information_schema 库中 Table 表里的字段： TABLE_SCHEMA : 数据库名TABLE_NAME：表名ENGINE：所应用的存储引擎TABLES_ROWS：记录数DATA_LENGTH：数据容量大小INDEX_LENGTH：索引容量大小 更多无关 information_schema 的信息，大家可在查看 MySQL 手册 深刻理解。 无关 information_schema.TABLES 更多字段信息，能够应用以下命令查看更多： use information_schemaSHOW COLUMNS FROM TABLES; 查看 MySQL「所有库」的容量大小SELECT table_schema as '数据库',sum(table_rows) as '记录数',sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)',sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)',sum(truncate(DATA_FREE/1024/1024, 2)) as '碎片占用(MB)'from information_schema.tablesgroup by table_schemaorder by sum(data_length) desc, sum(index_length) desc;特地提醒：data_length 、index_length 等字段，所存储的容量信息单位是字节，所以咱们要除以 2 个 1024 把字节转化为可读性更强的 MB，下文同理，不再累述。 ...

datetime和timestamp都是MySQL中的日期类型。 datetime类型以YYYY-MM-DD HH:MM:SS[.fraction]格局存储日期工夫： datetime = YYYY-MM-DD HH:MM:SSdatetime(6) = YYYY-MM-DD HH:MM:SS.fractiondatetime类型与时区无关(其值不随时区变动)，存储时占用8个字节。 timestamp类型存储自1970年1月1日到以后工夫的秒数，跟datetime相似，也以以YYYY-MM-DD HH:MM:SS[.fraction]格局展现。 timestamp类型与时区无关，配置不同的时区时其值不同。 timestamp存储时占用4个字节，工夫范畴：1970-01-01 ~ 2038-01-19。 timestamp类型的字段，能够在DDL语义中定义主动批改(ON UPDATE)： `updated_at` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp()demo次要演示datetime与timestamp随时区变动的状况。 设置以后时区： mysql> set time_zone='+8:00';Query OK, 0 rows affected (0.00 sec)创立表并插入数据： //d1 datetime类型； d2 timestamp类型mysql> create table t1(d1 datetime, d2 timestamp);Query OK, 0 rows affected (0.07 sec)mysql> insert into t1 values(now(), now());Query OK, 1 row affected (0.02 sec)查看以后数据： mysql> select * from t1;+---------------------+---------------------+| d1 | d2 |+---------------------+---------------------+| 2019-03-02 18:59:20 | 2019-03-02 18:59:20 |+---------------------+---------------------+1 row in set (0.01 sec)批改时区： ...

明天这篇文章将具体列出Mysql的学习流程，这是学习mysql数据库前你要理解的~~~ 大部分的小伙伴本人在网上找mysql材料、还有数据库的视频教程，然而都过于碎片化，没有体系，导致大家不晓得如何零碎的学习，也不晓得该如何零根底学习MySQL。 MySql概述MySQL最后是由“MySQL AB”公司开发的一套关系型数据库管理系统（RDBMS-Relational Database Mangerment System）。 MySQL不仅是最风行的开源数据库，而且是业界成长最快的数据库，每天有超过7万次的下载量，其利用范畴从大型企业到专有的嵌入利用零碎。 MySQL AB是由两个瑞典人和一个芬兰人：David Axmark、Allan Larsson和Michael “Monty” Widenius在瑞典开办的。 在2008年初，Sun Microsystems收买了MySQL AB公司。在2009年，Oracle收买了Sun公司，使MySQL并入Oracle的数据库产品线。 什么是数据库？数据库，通常是一个或一组文件，保留了一些合乎特定规格的数据,数据库对应的英语单词是DataBase,简称:DB,数据库软件称为数据库管理系统（DBMS），全称为DataBase Management System，如：Oracle、SQL Server、MySql、Sybase、informix、DB2、interbase、PostgreSql 。 MySQL的次要劣势：运行速度快，MySQL体积小，命令执行的速度快。应用成本低。MySQL是开源的，且提供收费版本，对大多数用户来说大大降低了应用老本。应用容易。与其余大型数据库的设置和治理相比，其复杂程度较低，易于应用。可移植性强。MySQL可能运行与多种零碎平台上，如windouws，Linux，Unix等。实用更多用户。MySQL反对最罕用的数据管理性能，实用于中小型企业甚至大型网站利用。MySQL教程目录：MySQL数据库概述及数据筹备MySQL教程MySQL装置教程SQL分类MySQL导入数据MySQL数据库表与MySQL表构造MySQL数据库常用命令MySQL数据库常用命令MySQL数据库查看表构造MySQL数据库查看表构造MySQL查问字段MySQL查问表字段MySQL条件查问MySQL条件查问MySQL排序MySQL排序MySQL函数MySQL函数MySQL分组函数/聚合函数/多行处理函数MySQL COUNT函数与MySQL聚合函数MySQL SUM函数与MySQL AVG函数MySQL Max()函数与MySQL MIN函数MySQL分组查问MySQL分组查问MySQL连贯查问MySQL连贯查问MySQL子查问MySQL子查问MySQL UNIONMySQL UNIONMySQL中limit的用法MySQL中limit的用法MySQL表MySQL创立表MySQL增加表字段、批改表字段及删除表字段MySQL增加表数据、批改表数据及删除表数据MySQL创立表并增加束缚MySQL实例教程：t_student和t_classes残缺示例MySQL增加束缚、删除束缚及批改束缚MySQL存储引擎MySQL存储引擎MySQL事务MySQL事务MySQL事务提交与回滚演示MySQL主动提交模式MySQL的事务隔离级别MySQL索引MySQL索引MySQL视图MySQL视图MySQL DBA命令MySQL DBA命令MySQL数据库设计的三大范式MySQL数据库设计的三大范式MySQL数据库练习题MySQL数据库练习题 以上就是mysql课程内容，能源节点老杜讲的mysql，就是专门为小白量身打造，每一个知识点都解说得十分细腻，由浅入深，配套的mysql教程材料也给大家筹备好了，戳下边链接 MySQL学习材料下载：https://www.bilibili.com/vide...

问咱们在 第12问 中介绍了 table cache 的作用: 在同一个线程内， 缩小了反复读取表定义的老本，包含读取表定义文件的 IO 老本， 和 结构内存构造的 CPU 老本。(要留神 table cache 是线程级别的) 同时咱们发现了一个问题， 即便没有命中 table cache ，MySQL 也不肯定会从表定义文件中读取。 这就是因为命中了 table definition cache (之后咱们简称为 TDC)，TDC 是全局级别的表定义缓存 本期咱们就来介绍一下 table definition cache 的作用 试验咱们的试验办法与 第12问 雷同 结构一个数据库： 咱们将 TDC 设置为最小值 400： 当初应用 sysbench，来结构500张表： 当初应用 strace 监听 MySQL 的 IO 操作： 接下来咱们将逐个拜访方才造出来的500张表，咱们先须要生成一个脚本： 咱们从 information_schema 中， 读取表名，并拼出相干的 SQL 当初就能够执行脚本了，咱们将方才生成的 SQL 通过管道符导入 MySQL client 进行执行： ...

作者：刘开洋 爱可生交付服务团队北京 DBA，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前几天来自生产上的一个问题，又涨常识了，明天拿来分享给大家。 景象与剖析景象是监控显示主从呈现提早，那咱们就得登上数据库看看到底呈现了什么事？ [root@localhost][(none)]> show slave status\G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.196.131.152 Master_User: universe_op Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.002805 Read_Master_Log_Pos: 929207906 Relay_Log_File: mysql-relay-bin.007053 Relay_Log_Pos: 588591867 Relay_Master_Log_File: mysql-bin.002805 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 588591694 Relay_Log_Space: 929208373 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 808 // 与主之间存在着808s的提早，并且提早还在减少Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 685734686 Master_UUID: 85d68147-e6a2-11ea-944a-0050568e99a5 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Waiting for dependent transaction to commit Master_Retry_Count: 1 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 85d68147-e6a2-11ea-944a-0050568e99a5:901602108-1056122204 // 收到的Gtid在增长，binlog dump Gtid线程正致力工作 Executed_Gtid_Set: 452dfe36-6508-11e9-85e2-00505694c5db:1-51354589, // gtid始终在增大，阐明从库继续在回放主库binlog，排除锁期待的状况85d68147-e6a2-11ea-944a-0050568e99a5:1-1056051538 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version:1 row in set (0.00 sec) // 在processlist中也能看到并发线程长时间Waiting for an event from Coordinator的景象[root@localhost][(none)]> show processlist;+--------+-------------+----------------------+------+-----------------+---------+---------------------------------------------------------------+------------------+| Id | User | Host | db | Command | Time | State | Info |+--------+-------------+----------------------+------+-----------------+---------+---------------------------------------------------------------+------------------+| 1 | system user | | NULL | Connect | 3459230 | Waiting for master to send event | NULL || 2 | system user | | NULL | Connect | 0 | Waiting for dependent transaction to commit | NULL || 3 | system user | | NULL | Connect | 811 | Waiting for an event from Coordinator | NULL || 4 | system user | | NULL | Connect | 811 | Executing event | NULL || 5 | system user | | NULL | Connect | 812 | Waiting for an event from Coordinator | NULL || 6 | system user | | NULL | Connect | 813 | Waiting for an event from Coordinator | NULL || 7 | system user | | NULL | Connect | 813 | Waiting for an event from Coordinator | NULL || 8 | system user | | NULL | Connect | 817 | Waiting for an event from Coordinator | NULL || 9 | system user | | NULL | Connect | 817 | Waiting for an event from Coordinator | NULL || 10 | system user | | NULL | Connect | 819 | Waiting for an event from Coordinator | NULL || 705000 | zabbix_user | 10.195.129.195:27258 | NULL | Sleep | 0 | | NULL || 705003 | zabbix_user | 10.195.129.195:27286 | NULL | Binlog Dump Gtid| 141604 | Master has sent all binlog to slave; waiting for more updates | NULL || 735026 | root | localhost | NULL | Query | 0 | starting | show processlist |+--------+-------------+----------------------+------+-----------------+---------+---------------------------------------------------------------+------------------+25 rows in set (0.00 sec) // 看看innodb存储引擎层整体的输入[root@localhost][(none)]> show engine innodb status\G*************************** 1. row *************************** Type: InnoDB Name:Status:=====================================2021-09-26 10:58:26 0x7f7964b63700 INNODB MONITOR OUTPUT=====================================Per second averages calculated from the last 3 seconds // 过来3s内的计算数值-----------------BACKGROUND THREAD-----------------srv_master_thread loops: 3451511 srv_active, 0 srv_shutdown, 37 srv_idlesrv_master_thread log flush and writes: 3451269----------SEMAPHORES // 通过上面的信号量阐明事件计数器和以后期待线程的列表很高，waits很高，存在很高的工作负载。----------OS WAIT ARRAY INFO: reservation count 1997792220OS WAIT ARRAY INFO: signal count 2815399081RW-shared spins 0, rounds 2610682598, OS waits 181278068RW-excl spins 0, rounds 93825427645, OS waits 1036416294 // 读写的锁计数器wait数量很高RW-sx spins 1902710329, rounds 36619607564, OS waits 565415695Spin rounds per wait: 2610682598.00 RW-shared, 93825427645.00 RW-excl, 19.25 RW-sx······之后咱们来到操作系统层面看看能找到哪些蛛丝马迹。首先是 IO ，此时回顾之前的景象是从库执行的 Gtid 始终在涨，那此时是否有很高的 IO 写入呢？ ...

一、Mysql最大连接数查问1、查看以后连接数查看以后连接数./mysqladmin -uroot -p1234.com statusUptime: 1370150 Threads: 1 （以后连接数） Questions: 79 Slow queries: 0 Opens: 33 Flush tables: 1 Open tables: 26 Queries per second avg: 0.000./mysql -uroot -p1234.com -e 'show status' | grep -i Threads Delayed_insert_threads 0Slow_launch_threads 0Threads_cached 1Threads_connected 1Threads_created 2Threads_running 1 ##（以后连接数）mysql> show status like 'Threads%';+-------------------+-------+| Variable_name | Value |+-------------------+-------+| Threads_cached | 1 || Threads_connected | 1 || Threads_created | 2 || Threads_running | 1 | ###以后连接数+-------------------+-------+4 rows in set (0.00 sec)2、查看最大连接数[root@xxx bin]# ./mysql -uroot -p1234.com -e 'show variables' | grep max_connectionsmax_connections 500mysql> show global variables like 'max_conn%';+--------------------+-------+| Variable_name | Value |+--------------------+-------+| max_connect_errors | 10 || max_connections | 500 |## 最大连接数+--------------------+-------+2 rows in set (0.00 sec)3、查看曾经用的连接数mysql> show global status like 'Max_used_connections';+----------------------+-------+| Variable_name | Value |+----------------------+-------+| Max_used_connections | 152 |+----------------------+-------+1 row in set (0.04 sec)————————————————二、计划想尽一切办法不重启 ...

大家好，我是月白。 写这篇文章不是比照 mysql 和 elasticsearch 的优劣（它们生而不同，没啥好比的），而是想分享一下最近在工作上遇到的一个查问问题和这个问题的解决过程。对于 elasticsearch，我也还是处在略懂阶段，要不是因为这次工作须要，我可能不会去钻研它 好了，回到正题，因为外部工作调整，接管了一个公司的边缘我的项目，体量并不大，几十万的用户数量。然而，就是这区区的几十万用户数量，导致了mysql in 查问参数过多的问题，经营在治理后盾查问客户列表速度迟缓甚至一度陷入瘫痪。 你可能会想，是不是代码写的太烂了或者后期设计考虑不周？ 其实这个也能了解，毕竟产品的需要是多变的，考虑不周是常有的事。这个列表查问本来只有几个简略的字段查问，而且都是客户表单表内的字段查问，随着产品的变更，查问条件多达十几个，其中这个标签查问，联表也解决不了问题，那具体是怎么一个状况呢？ 别急，让我简略介绍一下 问题简述为了集中于形容这个问题，表构造进行了惨无人道的简化，能领会到这个意思就好前端的展现就是上面这种分页表格（图片截图自 ant design 官网文档） 表构造客户表 custmers 字段类型idintnamestringgendertinyintageintremarkstringcreated_attimestampupdated_attimestamp标签表 tags 字段类型idintnamestringcreated_attimestampupdated_attimestamp关联表 customer_tag 字段类型customer_idinttag_idint查问需要当初产品须要通过客户名字以及客户身上的标签进行查问，反对多个标签同时查问。原来的sql大略是这样的 /* 获取符合要求的 customer_id 列表 查出来一大堆 customer_id */select customer_id from custmer_tag where tag_id in (传入的tag_id);/* 通过 customer_id 查问 每翻一页都得经验这一大堆id的in查问，id过多还会导致代码间接解体*/select * from customers where id in (一大堆id) limit 10 offset 0; 问题不言而喻了吧，in 查问内参数过多，不仅效率低下，极其状况还会导致sql过长程序解体。 看了第一眼我觉是不是能够援救一下（慢就慢一点，先让程序不异样），于是换成上面的语句： select * from customers where id in (select customer_id from custmer_tag where tag_id in (传入的 tag_id) group by customer_id));然而认真看了一下业务逻辑我就放弃了，多个 tag_id 查问 要反对 and 和 or 的查问逻辑，select customer_id from custmer_tag where tag_id in (1,2,3) group by customer_id 这句子查问 sql 就是 or 关系查问，customer 只须要存在任何一个 tag_id 就满足查问条件。然而如果是 and 逻辑呢？要查出同时存在标签 1，2，3 的客户，那么这条语句就不实用了。当然，如果肯定要用 sql 去查，兴许也能查出来，这里我就没有再试了，毕竟就算子查问行得通，效率也是非常低下的，不是长久之计。 ...

binary logbinary log记录了对Mysql数据库执行更改的所有操作（逻辑日志，不蕴含select,show这类没有对数据有批改的操作）。它是在存储引擎下层的数据库server层产生的。binary log的作用： 复原复制审计，用户能够通过binary log中的信息进行审计。binary log记录过程： 当开启一个事务时，所有未提交的binary log会被记录到一个缓存里。等事务提交时间接将缓存的binary log写入binary log文件里（磁盘）。该缓存可由binlog_chche_size进行调用，默认为32K。缓存同步磁盘能够通过sync_binlog进行调用，默认并不是每次写的时候同步到磁盘，宕机等极其状况下会呈现局部binary log失落。 binary log的格局： statement，基于SQL，如果存在uuid等函数会呈现主从服务器上数据不统一。row，记录行更改状况。mixed，在此格局下，默认应用statement格局进行记录，但呈现uuid等函数时会调整为row格局。redo logredo log被称为InnoDB存储引擎的日志文件。通常是物理日志，记录的是页的物理批改操作。redo log的作用： 保障事务的原子性与持久性redo log记录过程(可参考’InnoDB的两点个性‘里的double write)： 先写入一个重做日志缓冲。依照肯定条件程序地写入日志文件这里的‘肯定条件’有哪些条件呢？ 主线程每秒会将重做日志缓冲写入磁盘的重做日志文件中。由参数innodb_flush_log_at_trx_commit管制，示意在事务提交操作时解决重做日志的形式。binary log与redo log的差别点： binary log记录的是与数据库所有无关的日志，蕴含InnoDB等其它存储引擎的日志；redo log只记录与存储引擎相干的事务日志。binary log记录的都是对于一个事务的具体操作内容，是逻辑日志；redo log记录的是对于每个页更改的物理状况，是物理日志。写入工夫不同，binary log仅在事务提交前进行提交，只写磁盘一次，不管事务多大；而在事务进行过程中，会有多条redo log写入。binary log与redo log写入的整体过程： 当事务提交时InnoDB存储引擎进行筹备操作。mysql数据库下层写入二进制日志。InnoDB引擎层将日志写入重做日志文件。undo log事务有时还须要进行回滚操作，这时就须要undo logundo log保障事务的一致性，进行事务的回滚及MVCC性能的实现。 文章次要参考：《mysql技术底细》，及详细分析MySQL事务日志(redo log和undo log)

在 MySQL 中有两种存储工夫的数据类型 DATETIME 和 TIMESTAMP ，它们在数据库理论利用中，各有各的劣势和劣势。本文将具体详解两个数据类型的区别，以及用实战案例阐明它们的应用场景。 原文较长，完整版请跳转至源网站查看《在 MySQL 中 DATETIME 和 TIMESTAMP 工夫类型的区别及应用场景 - 实战案例解说 - 卡拉云》 一. DATETIME 和 TIMESTAMP 的相同点两个数据类型存储工夫的格局统一。均为 YYYY-MM-DD HH:MM:SS两个数据类型都蕴含「日期」和「工夫」局部。两个数据类型都能够存储微秒的小数秒（秒后6位小数秒）二. DATETIME 和 TIMESTAMP 的区别1.示意范畴DATETIME：1000-01-01 00:00:00.000000 到 9999-12-31 23:59:59.999999TIMESTAMP：'1970-01-01 00:00:01.000000' UTC 到 '2038-01-09 03:14:07.999999' UTC2.空间占用TIMESTAMP ：占 4 个字节（小数秒+3 个字节）DATETIME：在 MySQL 5.6.4 之前，占 8 个字节 ，之后版本，占 5 个字节。（小数秒+3 个字节）3. 存入工夫是否会主动转换？TIMESTAMP：TIMESTAMP 的值是从「以后工夫」转换成 UTC 工夫，或者反过来转换。DATETIME：不会做任何转换，也不会检测时区，你给什么数据，它存什么数据。4.应用 now() 存储以后工夫时，保留的理论值，是否与以后计算机工夫统一？TIMESTAMP：可能不统一。存储值会被转换成 UTC 工夫值再存入数据库。DATETIME：与以后工夫是统一的。5.如果存入的是 NULL 时，两个类型如何存储？TIMESTAMP：会主动存储以后工夫（ now() ）。DATETIME：不会主动存储以后工夫，会间接存入 NULL 值。三. 应用场景辨析在什么场景中，应用 DATETIME 或 TIMESTAMP 更适合？ ...

《高性能Mysql》学习笔记（三）前言 接续上文持续介绍：《高性能Mysql》学习笔记（二）。 索引B-Tree 索引 即没有特地指明的类型，大多数时候mysql 引擎都反对这种索引（Archive 是例外， 5.1 之前不反对，之后反对单个自增列的索引） 区别： myisam 应用物理地位保留 索引地位，并且对于索引进行了前缀压缩innodb 则依照原有数据格式保留数据，并且只有了主键的模式进行索引 外部都是依据存储引擎的实现而有了不同的区别 示例1. 首先创立一张表 2. 外部存储构造 索引对于多个值进行排序的依据是create table 当中定义索引时候的程序，看一下最初两个条目 上面的查问类型无效全值匹配 和索引当中所有的列进行匹配匹配最左前缀 只用索引的第一列匹配列前缀 匹配某一列值结尾的局部匹配范畴值：准确匹配某一列并范畴匹配另一列只拜访索引的查问 即只须要拜访索引即可，不须要索引，相似间接走聚簇索引B-Tree 索引的限度：如果不是从最左侧查找无奈应用索引不能跳过索引中的列如果查问中有某个列的范畴查问，则其左边所有的列都无奈应用优化查问哈希索引 基于哈希表实现，只有准确匹配索引所有列的查问才无效 mysql中只有 Memory 引擎反对哈希索引，这样说Memory 表默认的索引类型 限度哈希索引只蕴含哈希值和行指针，不存储字段值哈希索引数据并不是依照索引顺序存储，*无奈用于排序哈希索引不反对局部索引匹配查找，因为哈希索引始终是应用索引列的全部内容来计算哈希值的哈希只反对等值的比拟查问，不反对范畴查问拜访哈希数据十分快，哈希抵触的时候须要对于链表进行遍历哈希抵触高的时候，保护索引操作的代价也很高InnoDB 引擎的自适应哈希索引当某个索引值频繁应用的时候，会在内存中基于B-Tree 索引创立一个哈希索引 创立自定义哈希索引在B-Tree 上创立一个伪哈希索引 如下： 创立一个伪哈希索引；然而这样会有很高的查问开销应用上面语句能够对于性能的极大晋升 毛病： 须要手动保护哈希值，能够应用触发器或者手动保护实现 空间索引（R-Tree） myisam 表反对，具体内容能够自行搜寻，因为myisam引擎不是重点不做介绍 全文索引 查找文本当中的关键字 搜寻细节： 停用词词干复数布尔搜寻其余索引 Toku 引擎应用的树索引 索引的长处打打缩小服务器须要扫描的数据量帮忙服务器防止排序和长期表将随机I/O转变为程序I/O高性能索引策略独立的列前缀索引和索引的选择性 前缀索引能够使索引更小，更快的无效方法，然而mysql 有个缺点无奈对于前缀索引应用order by 和 group by,无奈应用前缀索引做笼罩扫描。 多列索引抉择适合的索引列程序教训法令： 1. 将选择性最高的列放在索引的最前列（不肯定精确） 2. 防止随机的IO和排序 ...