Mysql

从做完JavaWeb的我的项目之后，好久没关上过本地的MySQL，明天一关上忽然就打不开了，重复确认了MySQL服务是在运行中，依然是报1045权限谬误。 本地的MySQL只是用来调试，所以明码设置的很简略，也即是说不是因为明码谬误才会呈现1045谬误，具体我也不理解，然而如同如果良久关上过MySQL就会大略率性遇到这个谬误。 首先关上MySQL装置目录，找到my.ini文件，MySQL的配置文件，关上找到[mysqld]这一行，在上面加一行 skip-grant-tables而后保留，留神如果你的MySQL装置在C盘，得用管理员权限关上编辑器能力保留。而后关上服务治理重启MySQL，具体是win+r输出services.msc回车。 而后关上MySQL，在输出明码的时候间接回车就能够进入了，进去之后 use mysql;update user set password=password('123') where user = 'root' and host = 'localhost';flush privileges;再次重启MySQL服务，登陆的时候输出你设置的明码就能够登录了。

前言高并发这个阶段，必定是须要做读写拆散的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个状况，就是写一个主库，然而主库挂多个从库，而后从多个从库来读，那不就能够撑持更高的读并发压力了吗？那具体什么是读写拆散又如何解决其中的提早问题呢？赶快一起来看看吧！ 如何实现 MySQL 的读写拆散？其实很简略，就是基于主从复制架构，简略来说，就搞一个主库，挂多个从库，而后咱们就单单只是写主库，而后主库会主动把数据给同步到从库下来。 MySQL 主从复制原理的是啥？主库将变更写入 binlog 日志，而后从库连贯到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到本人本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，而后执行 binlog 日志中的内容，也就是在本人本地再次执行一遍 SQL，这样就能够保障本人跟主库的数据是一样的。 这里有一个十分重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个十分重要的点了，因为从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据肯定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒能力读取到。 而且这里还有另外一个问题，就是如果主库忽然宕机，而后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就失落了。 所以 MySQL 实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据失落问题；一个是并行复制，用来解决主从同步延时问题。 这个所谓半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立刻将数据同步到从库，从库将日志写入本人本地的 relay log 之后，接着会返回一个 ack 给主库，主库接管到至多一个从库的 ack 之后才会认为写操作实现了。 所谓并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，而后并行重放不同库的日志，这是库级别的并行。 MySQL 主从同步延时问题（精髓）以火线上的确解决过因为主从同步延时问题而导致的线上的 bug，属于小型的生产事变。 是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据，再把它查出来，而后更新这条数据。在生产环境高峰期，写并发达到了 2000/s，这个时候，主从复制延时大略是在小几十毫秒。线上会发现，每天总有那么一些数据，咱们冀望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给咱们。 咱们通过 MySQL 命令： show slave status复制代码查看 Seconds_Behind_Master ，能够看到从库复制主库的数据落后了几 ms。 一般来说，如果主从提早较为重大，有以下解决方案： 分库，将一个主库拆分为多个主库，每个主库的写并发就缩小了几倍，此时主从提早能够忽略不计。关上 MySQL 反对的并行复制，多个库并行复制。如果说某个库的写入并发就是特地高，单库写并发达到了 2000/s，并行复制还是没意义。重写代码，写代码的同学，要谨慎，插入数据时立马查问可能查不到。如果的确是存在必须先插入，立马要求就查问到，而后立马就要反过来执行一些操作，对这个查问设置直连主库。不举荐这种办法，你要是这么搞，读写拆散的意义就丢失了。出处。

MySQL的发展史MySQL的历史能够追溯到1979年，它的创始人叫作Michael Widenius，他在开发一个报表工具的时候，设计了一套API，起初他的客户要求他的API反对sql语句，他间接借助于mSQL（过后比拟牛）的代码，将它集成到本人的存储引擎中。然而他总是感觉不称心，萌发了要本人做一套数据库的想法。 一到1996年，MySQL 1.0公布，仅仅过了几个月的工夫，1996年10月MySQL 3.11.1过后公布了Solaris的版本，一个月后，linux的版本诞生，从那时候开始，MySQL缓缓的被人所承受。1999年，Michael Widenius成立了MySQL AB公司，MySQL由集体开发转变为团队开发，2000年应用GPL协定开源。 2001年，MySQL生命中的小事产生了，那就是存储引擎InnoDB的诞生！直到现在，MySQL能够抉择的存储引擎，InnoDB仍然是No.1。2008年1月，MySQL AB公司被Sun公司以10亿美金收买，MySQL数据库进入Sun时代。Sun为MySQL的倒退提供了绝佳的环境，2008年11月，MySQL 5.1公布，MySQL成为了最受欢迎的小型数据库。在此之前，Oracle在2005年就收买了InnoDB，因而，InnoDB始终以来都只能作为第三方插件供用户抉择。2009年4月，Oracle公司以74亿美元收买Sun公司，MySQL也随之进入Oracle时代。 2010年12月，MySQL 5.5公布，Oracle终于把InnoDB做成了MySQL默认的存储引擎，MySQL从此进入了辉煌时代。然而，从那之后，Oracle对MySQL的态度慢慢产生了变动，Oracle尽管声称MySQL仍然尊少GPL协定，但却暗地里把开发人员全副换成了Oracle本人人，开源社区再也影响不了MySQL倒退的脚步，真正有心做奉献的人也被拒之门外，MySQL随时都有闭源的可能…… 横空出世的MariaDB是什么鬼先提一下MySQL名字的由来吧，Michael Widenius的女儿的简称就是MY，Michael Widenius大略也是把MySQL当成本人的女儿吧。看着本人辛苦养大的MySQL被Oracle搞成这样，Michael Widenius十分悲观，决定在MySQL走向闭源前，将MySQL进行分支化，仍然是应用了本人女儿的名字MariaDB（玛莉亚DB）。 MariaDB数据库管理系统是MySQL的一个分支，次要由开源社区在保护，采纳GPL受权许可 MariaDB的目标是齐全兼容MySQL，包含API和命令行，使之能轻松成为MySQL的代替品。在存储引擎方面，应用XtraDB来代替MySQL的InnoDB。MariaDB由MySQL的创始人Michael Widenius主导，由开源社区的大神们进行开发。 因而，大家都认为，MariaDB领有比MySQL更纯正的MySQL血脉。最后的版本更新与MySQL同步，绝对MySQL5当前的版本，MariaDB也有相应的5.1~5.5的版本。起初MariaDB终于解脱了MySQL，它的版本号间接从10.0开始，以本人的步调进行开发，当然，还是能够对MySQL齐全兼容。当初，MariaDB的数据个性、性能等都超过了MySQL。 测试环境本性能测试环境如下： CPU：I7内存：8GOS：Windows 10 64位硬盘类型：SSDMySQL：8.0.19MariaDB：10.4.12别离在MySQl和MariaDB中创立名为performance的数据库，并创立log表，都应用innodb作为数据库引擎： CREATE TABLE `performance`.`log`(    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,  `time` DATETIME NOT NULL,  `level` ENUM('info','debug','error') NOT NULL,  `message` TEXT NOT NULL,  PRIMARY KEY (`id`)) ENGINE=INNODB CHARSET=utf8;插入性能单条插入单条插入的测试后果如下表所示： MariaDB 单条数据插入的性能比 MySQL 强1倍左右。 批量插入批量插入的测试后果如下表所示： 下面的测试后果，MariaDB 并没有绝对优势，甚至有时还比 MySQL 慢，但平均水平还是高于MySQL。 查问性能通过了屡次插入测试，我两个数据库里插入了很多数据，此时用上面的sql查问表中的数据量： SELECT COUNT(0) FROM LOG后果两个表都是6785000条，MariaDB用时3.065秒，MySQL用时6.404秒。此时我机器的内存用了6个G，MariaDB用了474284 K，MySQL只用了66848 K。看来MariaDB快是就义了空间换取的。 无索引先查问一下time字段的最大值和最小值： SELECT MAX(TIME), MIN(TIME) FROM LOG后果：MariaDB用时6.333秒，MySQL用时8.159秒。 接下来测试过滤time字段在0点到1点之间的数据，并对time字段排序： SELECT * FROM LOG WHERE TIME > '2020-02-04 00:00:00' AND TIME < '2020-02-04 01:00:00' ORDER BY TIME后果：MariaDB用时6.996秒，MySQL用时10.193秒。 而后测试查问level字符是info的数据： SELECT * FROM LOG WHERE LEVEL = 'info'后果：MariaDB用时0.006秒，MySQL用时0.049秒。 最初测试查问message字段值为debug的数据： SELECT * FROM LOG WHERE MESSAGE = 'debug'后果：MariaDB用时0.003秒，MySQL用时0.004秒。 有索引别离对两个数据库的字段创立索引： ALTER TABLE `performance`.`log`     ADD  INDEX `time` (`time`),  ADD  INDEX `level` (`level`),  ADD FULLTEXT INDEX `message` (`message`);MariaDB用时2分47秒，MySQL用时3分48秒。再用下面的测试项目进行测试，后果如下表所示： 有些后果增加了索引后还不如不加索引时现实，阐明理论应用时并不是每个字段都须要增加索引的。 总结在下面的测试中MariaDB的性能确实优于MySQL，看来各大厂商放弃MySQL拥抱MariaDB还是十分有情理的。 作者：swanmy 原文：blog.csdn.net/zhmh326/article/details/104168710

Gorm一条慢语句剖析背景早上被CTO @ 说是我的服务有一条语句要查问700K条数据，导致mysql记录了这条慢SQL，于是我连忙排查起因。。。 慢SQL记录 定位起因具体步骤查看索引有trade_symbol和KEY idx_tradesymbol_side_price_timestamp (trade_symbol,side,price,timestamp)两个能够应用的索引然而没有trade_symbol，timestamp，最终mysql抉择的索引是idx_tradesymbol_side_price_timestamp ，我本地建设trade_symbol，timestamp的联结索引，并去掉SQL中的, `deals`.`id` ASC语句，发现能够解决这个问题。 3.很奇怪的是我查找了我的代码，所有的代码中并没有应用ID主键作为排序的条件，主动更增加了ID ASC排序。 定位代码中应用的SQL如下，发现是因为应用了First这个函数，应用Find和Limit代替之后，就不会呈现这种状况了 var result = &orm.Deal{} err := db.Slave().Model(&orm.Deal{}).Where("trade_symbol = ?", symbol). Order("timestamp desc").First(result).Error return result.Price, err}总结教训对Gorm的实现原理没有了解测试的时候没有把SQL日志关上，查看日志数据的具体SQL语句

Ginblog（我的项目已实现，欢送应用)https://gitee.com/wejectchan/ginblog 重要更新2021.2.12 为了交换不便，建设了一个QQ群：951736723，如果有问题，欢送进群交换。2021.2.10 减少了展现页面的挪动端适配 2021.1.2 退出注册、登录、评论性能，后盾治理退出评论审核性能2021.1.3 减少 登录、注册验证性能；减少评论数量显示；减少浏览数量显示减少：文章页面评论数、阅读数介绍gin+vue 全栈制作一个博客。 这是一个分享全栈制作过程的我的项目，旨在为有趣味接触 golang web 开发的敌人分享一些制作教训。 你能够返回 B 站(https://space.bilibili.com/402177130) 观看全栈的制作过程，你也能够留言分享你的观点，十分乐意与你交换。 目录构造├─ .gitignore│ go.mod // 我的项目依赖│ go.sum│ latest_log.log│ LICENSE│ main.go //主程序│ README.md│ tree.txt│ ├─api ├─config // 我的项目配置入口 ├─database // 数据库备份文件（初始化）├─log // 我的项目日志├─middleware // 中间件├─model // 数据模型层├─routes│ router.go // 路由入口 ├─static // 打包动态文件│ ├─admin // 后盾治理页面 │ └─front // 前端展现页面 ├─upload ├─utils // 我的项目专用工具库│ │ setting.go │ ├─errmsg │ └─validator └─web // 前端开发源码（VUECLI我的项目源文件) ├─admin └─front运行&&部署克隆我的项目 ...

mysql中的锁1、锁的类型 共享锁，容许事务读取一行数据排他锁，容许事务删除或更新一条数据多粒度锁定，这种锁定容许事务在行级上的锁和表级上的锁同时存在，为了反对在不同粒度上进行加锁操作，innodb反对一种额定的锁形式，称之为意向锁意向锁：意味着事务心愿在更细粒度上进行加锁动向共享锁：事务想要获取一张表中的某几行的共享锁动向排它锁：事务想要获取一张表中的某几行的排它锁2、一致性非锁定读 是innodb通过多版本控制的形式来读取以后工夫数据库中行的记录。如果读取的行正在进行update或者delete操作，则不会期待以后行的排它锁开释。相同，innodb会去读取一个行的快照版本。read committed和repeatableread都是应用一致性非锁定度，不过readcommitted总是读取被锁定行的最新一份快照数据，repeatableread总是读取事务开始时的数据版本。例如：A，begin;select id from t where id = 1;B,begin;update t set id = 3 where id=1;此时A中再次select id from t where id = 1;不论是readcommitted还是repeatableread后果都为1。Bcommit此时A中再次select id from t where id = 1;readcommitted是null，是repeatableread后果为1。3、一致性锁定读 select for update;select Lock in share mode;4、外键和锁 innodb在增加外键的时候会被动给外键的列加上索引对于外键的插入和更新须要应用一致性锁定读来查问父表select Lock in share modeA begin;delete from t where id = 3;Bbegin;insert into t2 select(2,3)；第二列是外键A会对3这行数据加上x锁，B会对3这样数据加上s锁，加不上，无奈插入，如果不加s锁，那么新增胜利则会造成数据不统一；5、锁的算法 行锁的三种算法record lock:单个行记录上的锁GapLock:间隙锁，锁定一个范畴，但不蕴含记录自身Next key Lock:GapLock+recordLock,范畴加记录自身。对于惟一索引，加的是record lock对于不同索引，加的是NextKeyLockinsert into z values(3,1)insert into z values(5,3);insert into z values(7,6)A select * from z where b = 3 for update;首先用recordLock锁定a=5,而后用nextKeyLock锁定b=3，(1,3]和(3,6)如果不应用nextKeyLock那么insert into z values(6,3)能够胜利，那么A中再次执行同样的操作就会取得不同的后果，phantom problem.用户能够通过nextKeyLock机制在应用层实现唯一性查看select * from twhere col = xxx Lock in share mode;if not found any row;insert into table values();6、脏读7、不可反复读8、失落更新 ...

1、参数文件2、日志文件 2.1、谬误日志2.2、慢查问日志2.3、查问日志2.4、二级制日志3、表构造文件4、innodb存储文件 4.1、表空间文件4.2、重做日志文件5、二进制日志文件写入机会 二进制日志首先是写入到二进制日志缓冲中，在事务提交的时候，在写入到二进制日志文件中6、重做日志文件写入机会 重做日志在事务的过程中就会写入到重做日志中7、二进制日志和重做日志的区别 1、二进制日志是在mysqlservice层，重做日志是在innodb层2、二进制日志记录的逻辑操作，重做日志记录的是对页的物理操作。3、写入的机会不同，二进制日志文件仅在事务提交前进行提交，只写磁盘一次，不管事务多大。而在事务进行过程中却一直有重做日志条目被写入到重做日志中。~~~~

关键词：MySQL Index Merge前言MySQL 的锁机制置信大家在学习 MySQL 的时候都有简略的理解过，那既然有锁就必然绕不开死锁这个问题。其实 MySQL 在大部分场景下是不会存在死锁问题的（比方并发量不高，SQL 写得不至于太拉胯的状况），然而在高并发的业务场景下，一不注意就会产生死锁，而这个死锁剖析起来也比拟麻烦。 前段时间在公司实习的时候就遇到了一个比拟奇怪的死锁，之前始终没来得及好好整顿，最近有空复现了一下，算是积攒一点教训。 业务场景简略说一下业务背景，公司做的是电商直播，我负责的是主播端相干的业务。而这个死锁就呈现在主播后盾对商品信息进行更新的时候。 咱们的一个商品会有两个关联的 ID，通过其中任何一个 ID 都无奈确定惟一一件商品（也就是说这个 ID 和商品是一对多的关系），只能同时查问两个 ID，能力确定一件商品。所以在更新商品信息的时候，须要在 where 条件中同时指定两个 ID，上面是死锁 SQL 的构造（已脱敏）： UPDATE test_table SET `name`="zhangsan" WHERE class_id = 10 AND teacher_id = 8;这个 SQL 非常简单，依据两个等值条件，对一个字段进行更新。 不晓得你看到这个 SQL 会不会懵逼，按常理来说，应该是一个事务里有多条 SQL 才会有可能呈现死锁，这一条 SQL 怎么可能呈现死锁呢？ 是的，我过后也有这样的纳闷，甚至狐疑是不是报警零碎瞎报（最初证实不是…），过后是真的摸不着头脑。并且因为数据库权限的起因，想看死锁日志都看不到，又是邻近上班的时候，找 DBA 能麻烦死，所以就间接搜索引擎走起了……（关键词：update 死锁 单条 sql），最初查出来是因为 MySQL 的索引合并优化导致的，即 Index Merge，上面会进行具体解说并复现一下死锁场景。 索引合并Index Merge 是 MySQL 在 5.0 的时候引入的一项优化性能，次要是用于优化一条 SQL 应用多个索引的状况。 咱们来看刚刚的 SQL，假如 class_id 和 teacher_id 别离是两个一般索引： ...

谬误形容:自定义函数参数名称与函数体中 where子字句中表的列明雷同时报错;如图表信息如下: 谬误提醒如下:解决办法批改参数名称,具体如下

表锁（偏读）偏差MyISAM存储引擎。开销小，加锁快，无死锁，锁定粒度大，产生锁抵触的概率最高，并发最低。 查看以后数据库中表的上锁状况，0示意未上锁。show open tables;增加读/写锁lock table 表名 read(write) , 表名2...开释表锁unlock table;加读锁（共享）以后会话和其余会话均可读取加了读锁的表以后会话不能读取其余表（先把本人的事干好）其余会话要批改加了读锁的表，必须期待锁开释（阻塞状态）加写锁（独占）以后会话能够读取和批改加了写锁的表以后会话也不能读取其余的表（先把本人的事干好）其余会话想要读取加了写锁的表，必须期待锁开释（阻塞状态）论断MyISAM在执行查问语句时，会主动给波及的所有表加读锁。再执行增删改操作时，会主动给波及的表加写锁。 简而言之，就是读锁会阻塞写，然而不会阻塞读。而写锁则会把读和写都阻塞。 表锁的剖析查看哪些表被锁了，0表锁未锁：show open table通过 show status like 'table%'命令 Table_locks_immediate：产生表级锁定的次数，每立即获取一次，锁值加1Table_locks_waited：不能立即获取锁的次数，每期待一次锁值加1。此值高阐明存在重大的表级锁争用状况。此外，MyISAM是写锁优先调度，这也是不适宜做主表的引擎。因为写锁后，其余线程不能做任何操作，大量的更新会使查问很难失去锁，从而造成永远阻塞。行锁（偏写）偏差InnoDB存储引擎。开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低，并发度也最高。 InnoDB与MyISAM的最大两个不同点：①反对事务，②采纳了行级锁 操作同一行数据批改表中的同一行数据，将导致 session2 产生阻塞，一旦 session1 提交事务，session2 将执行更新操作。 操作不同行数据因为采纳行锁，session2 和 session1 互不干涉，所以 session2 中的批改操作没有阻塞 无索引导致行锁降级为表锁 session1 set autocommit=0; #敞开主动提交事务#varchar数据类型不必‘’，导致系统主动转换类型，导致索引生效update test_innodb_lock set a=44 where b=4000; session2 set autocommit=0;update test_innodb_lock set b='9001' where a=9; #执行发现产生了阻塞session中的SQL语句索引生效，导致行锁变为表锁。session2须要期待session1提交事务开释锁。为什么建表后要创立索引？因为不创立索引的话，更新操作的时候，行锁会因为没有索引而变为表锁。想要锁定某一行时，在前面加上：for update，其余的操作会被阻塞，晓得锁定行的会话提交。 总结InnoDB实现了行级锁定，带来的性能损耗比表级锁定会更高一些，然而在整体并发解决能力方面要远远优于MyISAMInnoDB的行级锁也有软弱的一面，当咱们使用不当的时候（索引生效变为表锁），可能会让InnoDB的整体性能比MyISAM的差。事务事务的个性个性阐明原子性（Atomicity）一个事务中的所有操作，要么全副胜利，要么全副失败一致性（Consistency）事务开始之前和完结之后，数据库的完整性没有被毁坏隔离性（Isolation）不同事务之间互不影响（有四种隔离级别）持久性（Durability）事务一旦提交，其后果就会长久化，就算产生宕机也能复原数据一致性的例子：转账来说，A和B的钱一共5000，不论A和B如何转账，事务完结后A和B的钱加起来还得是5000。数据库层面怎么实现事务？ InnoDB曾经帮咱们开启了事务，并且每一条语句都会主动提交。如果要保障多条语句的事务性，就要手动开启事务。InnoDB存储引擎对ACID的实现形式利用回滚日志（undo log） 和 重做日志（redo log） 两种表实现事务，并实现 MVCC (多版本并发管制)； redo log（重做日志）用于记录数据批改后的状态每当有操作执行前，先将相干操作写入redo log。这样当断电等意外产生时，零碎复原后，能够持续实现这些更改。Binlog日志的两个最重要的应用场景？MySQL主从复制数据恢复（通过mysqlbinlog工具）redolog 和 binlog的区别？redolog是InnoDB特有的，binlog是MySQL的Server层实现的，所有引擎都能应用。redolog是物理日志，binlog是逻辑日志redolog是循环着写的，会笼罩，因为空间是固定的会用完。binlog是追加写的，写到肯定大小后会切换到下一个。redolog在事务执行过程中一直写入，binlog是在事务最终提交前写入的。undo log（回滚日志）用于记录数据批改前的状态当一些更改执行一半发生意外时，而无奈实现，则能够依据undo log复原到之前的版本。（undolog记录的是逻辑日志）相同的记录。当delete一条记录时，undo log 中会记录一条对应的 insert 记录，反之亦然。当 update 一条记录时，它记录一条对应相同的 update 记录。例如某一时刻数据库宕机了，有两个事务，一个事务曾经提交，另一个事务正在解决。数据库重启后，就要依据日志进行前滚或回滚。把已提交事务的更改写到数据文件，未提交的事务更改复原到事务开始前的状态。MySQL中ACID底层实现原子性：次要依附undo.log日志实现，即在事务失败时执行回滚。持久性：次要依附redo.log日志实现。首先，MySQL长久化通过缓存来提高效率。但因为缓存断电就没了，所以须要redo.log日志。在执行批改操作时，sql会先写入到redo.log日志，再写入缓存中。这样即便断电，也能保证数据不失落，达到持久性隔离性：数据库四种隔离级别，通过MVCC和锁实现。一致性：而下面三种个性就是为了保障数据库的有一致性（redolog+undolog）事务并发带来的问题失落更新：（更新操作 加上排它锁来防止）某一个事务的回滚或提交，导致另一个事务已更新数据的失落脏读：读取了其余并发事务未提交的数据。毁坏了事务的隔离性。不可反复读：读取了其余并发事务提交的数据。针对update和delete，也是毁坏了事务的隔离性。幻读：读取了其余并发事务提交的数据。针对insert ...

1 问题形容Docker启动MySQL容器后，创立一个localhost拜访的用户： create user test@localhost identified by 'test';然而在宿主机中无奈通过该用户登录： mycli -u test 2 起因在Docker中的MySQL创立localhost的用户只能在Docker外部拜访，而不能通过内部拜访。 至于为什么能在宿主机拜访root，是因为默认存在两个root，别离是： root@localhostroot@% 而test只有一个localhost： 3 解决方案创立test@%或者创立test@172.17.0.1即可： create user test@% identified by 'test';create user test@172.17.0.1 identified by 'test';

1、mysql数据库意识数据库和数据库实例的区别数据库对应数据库文件，数据库实例2、后盾线程master线程：刷新缓存到磁盘、回收undolog、insertbufferIO threadpurge threadpage cleaner thread2、innodb内存缓存池+redolog缓存缓冲池：通过lru来算法来治理内存LRU LIST 负责管理缓冲池中页的可用性FREE LISTFLUSH LIST 用来治理将页刷新回磁盘重做日志缓冲：innodb存储引擎首先将重做日志信息先放入到这个缓冲区，而后在意肯定的频率将其刷新到重做日志中3、checkpoint技术假使每个页产生一次变动就将新页刷新到磁盘，开销是很微小。另外，如果在刷新的过程中如果宕机，那么内存中的数据就会失落。所以以后事务性数据库都采纳write ahead log 策略，即当事务提交时，先写重做日志，在批改页。当产生宕机时，通过重做日志来实现数据的复原。6、innodb要害个性6.1、插入缓冲（insert buffer）    条件：1、辅助索引2、非惟一索引   解决的问题：非惟一的辅助索引插入时，因为b+树的构造特点，须要离散的拜访该索引页。6.2、两次写（double write）    两次写能够带来数据页的可靠性    你可能会想到，如果产生写失落，能够通过重做日志来复原。但必须分明的意识到，重做日志中记录的都是对页的物理操作，比方偏移量800，写‘aaa’记录。如果这个页自身曾经产生了损坏，在对其进行重做是没有意义的。这就是说，在利用重做日志钱，用户须要一个正本，当写入生效产生时，先通过页的副原本还原这个页，再进行重做，这就是两次写。    实现：在刷新缓存时，并不是间接写磁盘，而是先将脏页复制到doublewrite buffer（2M）中,通过doublewriter buffer再分两次每次1M程序地写入到共享表空间的磁盘上，实现之后，再将doublewrite buffer中的页各个表空间文件中。如果在刷缓存的时候宕机了，那么会先从共享表空间中找到这个页的正本，还原该页，再进行redolog的数据恢复。

作者：杨磊墨天伦社区 MVP、DBASK 技术专家、ACDU 外围搭档；某航司数据架构师，专一于数据业余畛域工作近10年，始终致力于数据畛域开源化、国产化、新技术钻研和利用，对数据生态链中的国产数据库、开源库、数据缓存、大数据、分布式存储和计算、云计算有亲密关注。 微信公众号：一森咖记。 本文起源：转载自公众号-戏说数据那点事 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 引言大家都晓得数据库事务四个性：原子性、一致性、隔离性和持久性，也就是人们熟知的 ACID 个性。在理论生产利用中，数据库中的数据是要被多用户共享/拜访，而在多个用户同时操作雷同数据时，可能会呈现一些事务的并发问题，这就就有了事务隔离性的四种不同级别。明天，本文将围绕事务的个性、并发问题、隔离级别进行集中学习。 之前的一篇相干推文介绍过 MySQL 的三种锁：《浅谈MySQL三种锁：全局锁、表锁和行锁》 链接：https://mp.weixin.qq.com/s?__...首先回顾下事物的概念： 一个事务中的一系列的解决操作操作要么全副胜利，要么一个都不做。在数据库操作中，一项事务（Transaction）是由一条或多条操作数据库的 SQL 语句组成的一个不可分割的工作单元。 那么，事务的解决完结就会有两种：当事务中的所有步骤全副胜利执行时，事务提交，胜利；如果其中任何一个步骤失败，该事务都将产生回滚操作，吊销已执行的所有操作。再来看下事务的四个个性： 1）原子性（Atomic） 示意将事务中所进行的操作捆绑成一个不可分割的单元，即对事务所进行的数据批改等操作，要么全副执行，要么全不执行；如果失败，就回滚到事务开始前的状态。 2）一致性（Consistency） 事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 3）隔离性（Isolation） 指一个事务的执行不能被其余事务烦扰，即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。 4）持久性（Durability） 持久性也称永久性（permanence），持久性就是指如果事务一旦被提交，数据库中数据的扭转就是永久性的，即便断电或者宕机的状况下，也不会失落提交的事务操作。 **本文主讲隔离性，这里再把事务的隔离性（Isolation）单拉进去阐明下：**隔离性是指，多个用户的并发事务拜访同一个数据库时，一个用户的事务不应该被其余用户的事务烦扰，多个并发事务之间要互相隔离。 事务隔离性的重要性： 事务的隔离性次要是从晋升数据库的数据处理速度，即并发角度思考的；换句话说，事务隔离性和整体数据库的性能/并发执行，有间接决定性作用。 一个思维模式：想要了解一个知识点，就假如如果没有该点会有什么产生；事务隔离性也是，如果事务中没有隔离性这个概念，会产生点啥事？ 在理论利用中，数据库中性能的好坏规范之一就是数据能被尽可能多的用户独特拜访，当多个用户同时解决同一数据时，可能就会呈现一些事务的并发问题，导致如下四种状况呈现： 1）脏读 指一个事务读取到另一个事务未提交的数据。 2）不可反复读 指一个事务对同一行数据反复读取两次，但失去的后果不同。 举例：事务 1 读取表的一条数据期间，事务 2 更新了该条记录并提交，事务 1 再次读取该表该条记录时，发现和第一次内容不统一。 3）幻读 指一个事务执行两次查问，但第二次查问的后果蕴含了第一次查问中未呈现的数据。 举例：事务 1 读取一个表期间，事务 2 对表做了 delete/update/insert 操作并提交，事务 1 再次读取表时，此时读取到事务 2 操作的记录，两次操作后果不统一。 这里，有敌人会问，不可反复读和幻读这不一样吗？ 答案为：不一样。有啥区别？ 幻读和不可反复读都是读取了另一条曾经提交的事务；但不可反复读查问的都是同一个数据项，而幻读针对的是一批数据整体（比方数据的个数）。 不可反复读和幻读是初学者不易分清的概念；简略来说，解决不可反复读的办法是大家常说的加行锁，解决幻读形式是加表锁。 4）失落更新 指两个事务同时更新一行数据，后提交（或撤销）的事务将之前事务提交的数据笼罩了。 留神：失落更新可分为两类，别离为第一类失落更新和第二类失落更新。 第一类失落更新：两个事务同时操作同一个数据时，当第一个事务撤销时，把曾经提交的第二个事务的更新数据笼罩了，第二个事务就造成了数据失落。 第二类失落更新：当两个事务同时操作同一个数据时，第一个事务将批改后果胜利提交后，对第二个事务曾经提交的批改后果进行了笼罩，对第二个事务造成了数据失落。 能够看出，上述问题，均是在并发状况下产生的，并发度越高，上述呈现的状况也广泛。 怎么办？为了防止上述事务并发问题的呈现，规范 SQL 标准定义了四种事务隔离级别，不同的隔离级别对事务的解决有所不同。这四种事务的隔离级别如下： ...

索引优化剖析join查问SQL执行程序mysql 从 FROM 开始执行~ join连贯查问 7 种 JOIN 示例建表tbl_dept 表构造（部门表）mysql> select * from tbl_dept;+----+----------+--------+| id | deptName | locAdd |+----+----------+--------+| 1 | RD | 11 || 2 | HR | 12 || 3 | MK | 13 || 4 | MIS | 14 || 5 | FD | 15 |+----+----------+--------+5 rows in set (0.00 sec)tbl_emp 表构造（员工表）mysql> select * from tbl_emp;+----+------+--------+| id | NAME | deptId |+----+------+--------+| 1 | z3 | 1 || 2 | z4 | 1 || 3 | z5 | 1 || 4 | w5 | 2 || 5 | w6 | 2 || 6 | s7 | 3 || 7 | s8 | 4 || 8 | s9 | 51 |+----+------+--------+8 rows in set (0.00 sec)笛卡尔积tbl_emp 表和 tbl_dept 表的笛卡尔乘积：select * from tbl_emp, tbl_dept;其后果集的个数为：5 * 8 = 40inner jointbl_emp 表和 tbl_dept 的交加局部（公共局部） ...

前言： 在数据库运维过程中，咱们时常会关注数据库的链接状况，比方总共有多少链接、有多少沉闷链接、有没有执行工夫过长的链接等。数据库的各种异样也能通过链接状况间接反馈进去，特地是数据库呈现死锁或重大卡顿的时候，咱们首先应该查看数据库是否有异样链接，并杀掉这些异样链接。本篇文章将次要介绍如何查看数据库链接及如何杀掉异样链接的办法。 1.查看数据库链接查看数据库链接最罕用的语句就是 show processlist 了，这条语句能够查看数据库中存在的线程状态。普通用户只能够查看以后用户发动的链接，具备 PROCESS 全局权限的用户则能够查看所有用户的链接。 show processlist 后果中的 Info 字段仅显示每个语句的前 100 个字符，如果须要显示更多信息，能够应用 show full processlist 。同样的，查看 information_schema.processlist 表也能够看到数据库链接状态信息。 # 普通用户只能看到以后用户发动的链接mysql> select user();+--------------------+| user() |+--------------------+| testuser@localhost |+--------------------+1 row in set (0.00 sec)mysql> show grants;+----------------------------------------------------------------------+| Grants for testuser@% |+----------------------------------------------------------------------+| GRANT USAGE ON *.* TO 'testuser'@'%' || GRANT SELECT, INSERT, UPDATE, DELETE ON `testdb`.* TO 'testuser'@'%' |+----------------------------------------------------------------------+2 rows in set (0.00 sec)mysql> show processlist;+--------+----------+-----------+--------+---------+------+----------+------------------+| Id | User | Host | db | Command | Time | State | Info |+--------+----------+-----------+--------+---------+------+----------+------------------+| 769386 | testuser | localhost | NULL | Sleep | 201 | | NULL || 769390 | testuser | localhost | testdb | Query | 0 | starting | show processlist |+--------+----------+-----------+--------+---------+------+----------+------------------+2 rows in set (0.00 sec)mysql> select * from information_schema.processlist;+--------+----------+-----------+--------+---------+------+-----------+----------------------------------------------+| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO |+--------+----------+-----------+--------+---------+------+-----------+----------------------------------------------+| 769386 | testuser | localhost | NULL | Sleep | 210 | | NULL || 769390 | testuser | localhost | testdb | Query | 0 | executing | select * from information_schema.processlist |+--------+----------+-----------+--------+---------+------+-----------+----------------------------------------------+2 rows in set (0.00 sec)# 授予了PROCESS权限后，能够看到所有用户的链接mysql> grant process on *.* to 'testuser'@'%';Query OK, 0 rows affected (0.01 sec)mysql> flush privileges;Query OK, 0 rows affected (0.00 sec)mysql> show grants;+----------------------------------------------------------------------+| Grants for testuser@% |+----------------------------------------------------------------------+| GRANT PROCESS ON *.* TO 'testuser'@'%' || GRANT SELECT, INSERT, UPDATE, DELETE ON `testdb`.* TO 'testuser'@'%' |+----------------------------------------------------------------------+2 rows in set (0.00 sec)mysql> show processlist;+--------+----------+--------------------+--------+---------+------+----------+------------------+| Id | User | Host | db | Command | Time | State | Info |+--------+----------+--------------------+--------+---------+------+----------+------------------+| 769347 | root | localhost | testdb | Sleep | 53 | | NULL || 769357 | root | 192.168.85.0:61709 | NULL | Sleep | 521 | | NULL || 769386 | testuser | localhost | NULL | Sleep | 406 | | NULL || 769473 | testuser | localhost | testdb | Query | 0 | starting | show processlist |+--------+----------+--------------------+--------+---------+------+----------+------------------+4 rows in set (0.00 sec)通过 show processlist 所得后果，咱们能够清晰理解各线程链接的详细信息。具体字段含意还是比拟容易了解的，上面具体来解释下各个字段代表的意思： ...

一位喜好技术的橘右京的哥哥橘左京 前言：什么是存储过程？存储过程就像是一个接口，能够间接去调用，不须要反复的编写。 1.1 存储过程和函数概述存储过程和函数是当时通过编译并存储在数据库的一段SQL语句的汇合，调用存储过程和函数能够简化开发人员的很多工作，缩小数据和应用服务器之间的传输，对于进步数据处理的效率是有益处的。存储过程和函数的区别在于函数必须有返回值，而存储过程没有。1.2 创立存储过程语句： delimiter $create procedure 存储过程名称()begin SQL语句;end$释义：delimiter的中文解释为‘分隔符’，示意将“$”代替“;”设置为分隔符,因为在begin后的SQL语句中须要以";"结尾,所以就要设置一个与";"辨别开的分隔符。 1.3 调用存储过程语法：call 存储过程名称;执行创立存储过程实现后，应用调用办法调用存储过程。1.4 查看存储过程查询数据库中的存储过程 select name from mysql.proc where db = 'test'查问存储过程的状态信息 show procedure status;1.5 变量· DECLARE通过DECLARE能够定义一个变量，该变量的作用范畴用于BEGIN...END之间1.5.1 申明变量示例：案例：申明一个年龄变量并查问值 delimiter $create procedure 存储过程名称()begindeclare age int default 0;select concat('num的值是',age);end $1.5.2 SET赋值示例：案例：申明一个年龄变量并通过SET赋值后查问值 delimiter $create procedure 存储过程名称()begindeclare num int default 0;set num = num + 10;select concat('num的值是',num);end $1.5.3 select ...into...赋值示例：案例：申明一个年龄变量并通过SELECT INTO 赋值后查问值 delimiter $create procedure 存储过程名称()begindeclare num int;select count(1) into num from bsx_user;select num;end $1.6 IF语法判断案例：当年龄段为12岁以下输入青年，当年龄在12-17输入青少年，18-29岁输入青年 ...

大家好，我是来自JDL京东物流技术发展部邢焕杰， 明天来分享一个京东面试真题，这也是我前阵子听我工位旁边高T（高，实在是高）面试候选人的时候问的一个问题，他问，你能说说 MySQL的事务吗？MVCC有理解吗？话不多说，本文就深度解析一下MySQL事务及MVCC的实现原理。事务定义及四大个性事务是什么？事务的四大个性（简称ACID）：原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包含的操作要么都做，要么都不做。一致性（Consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。隔离性（Isolation）：一个事务的执行不能被其余事务烦扰。即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰.持久性（Durability）：指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的,接下来的其余操作或故障不应该对其有任何影响。事务中常见问题脏读（dirty read）：就是一个A事务即使没有提交，它对数据的批改也能够被其余事务B事务看到，B事务读到了A事务还未提交的数据，这个数据有可能是错的，有可能A不想提交这个数据，这只是A事务批改数据过程中的一个两头数据，然而被B事务读到了，这种行为被称作脏读，这个数据被称为脏数据不可反复读（non-repeatable read）：在A事务内，屡次读取同一个数据，然而读取的过程中，B事务对这个数据进行了批改，导致此数据变动了，那么A事务再次读取的时候，数据就和第一次读取的时候不一样了，这就叫做不可反复读幻读（phantom read）：A事务屡次查询数据库，后果发现查问的数据条数不一样，A事务屡次查问的距离中，B事务又写入了一些合乎查问条件的多条数据（这里的写入能够是update，insert，delete），A事务再查的话，就像产生了幻觉一样，怎么忽然扭转了这么多，这种景象这就叫做幻读隔离级别——产生问题的起因多个事务相互影响，并没有隔离好，就是咱们方才提到的事务的四大个性中的 隔离性（Isolation） 呈现了问题 事务的隔离级别并没有设置好，上面咱们来看下事务到底有哪几种隔离级别 隔离级别读未提交（read uncommitted RU）： 一个事务还没提交时，它做的变更就能被别的事务看到读提交（read committed RC）： 一个事务提交之后，它做的变更才会被其余事务看到。可反复读（repeatable read RR）： 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。当然在可反复读隔离级别下，未提交变更对其余事务也是不可见的。串行化（serializable ）： 顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。咱们来看个例子，更加直观的理解这四种隔离级别和上述问题脏读，不可反复读，幻读的关系 上面咱们探讨下当事务处于不同隔离级别状况时，V1,V2,V3别离是什么不同的值吧 读未提交 (RU)： A事务能够读取到B事务批改的值，即使B事务没有提交。所以V1就是200V1 : 200V2 : 200V3 : 200读提交（RC）： 当B事务没有提交的时候，A事务不能够看到B事务批改的值，只有提交当前才能够看到V1 : 100V2 : 200V3 : 200可反复读（RR）： A事务屡次读取数据，数据总和第一次读取的一样，V1 : 100V2 : 100V3 : 200串行化（S）： 事务A在执行的时候，事务B会被锁住，等事务A执行完结后，事务B才能够继续执行V1 : 100V2 : 100V3 : 200MVCC原理MVCC（Multi-Version Concurrency Control）多版本并发管制，是数据库管制并发拜访的一种伎俩。 特地要留神MVCC只在 读已提交(RC) 和 可反复度（RR） 这两种事务隔离级别下才无效是 数据库引擎（InnoDB） 层面实现的，用来解决读写抵触的伎俩（不必加锁），进步拜访性能MVCC是怎么实现的呢？它靠的就是版本链和一致性视图 1. 版本链版本链是一条链表，链接的是每条数据已经的批改记录那么这个版本链又是如何造成的呢，每条数据又是靠什么链接起来的呢？ 其实是这样的，对于InnoDB存储引擎的表来说，它的聚簇索引记录蕴含两个暗藏字段 trx_id: 存储批改此数据的事务id，只有这个事务操作了某些表的数据后当更改操作产生的时候（update,delete,insert），才会调配惟一的事务id,并且此事务id是递增的roll_pointer: 指针，指向上一次批改的记录row_id(非必须): 当有主键或者有不容许为null的unique键时，不蕴含此字段如果说以后数据库有一条这样的数据，假如是事务ID为100的事务插入的这条数据，那么此条数据的构造如下 起初，事务200，事务300，别离来批改此数据 所以此时的版本链如下 咱们每更改一次数据，就会插入一条undo日志，并且记录的roll_pointer指针会指向上一条记录，如图所示 第一条数据是小杰，事务ID为100事务ID为200的事务将名称从小杰改为了A事务ID为200的事务将名称从A又改为了B事务ID为300的事务将名称从B又改为了C所以串成的链表就是 C -> B -> A -> 小杰 （从最新的数据到最老的数据） 2. 一致性视图（ReadView）须要判断版本链中的哪个版本是是以后事务可见的，因而有了一致性视图的概念。其中有四个属性比拟重要 m_ids: 在生成ReadView时，以后沉闷的读写事务的事务id列表min_trx_id: m_ids的最小值max_trx_id: m_ids的最大值+1creator_trx_id: 生成该事务的事务id，单纯开启事务是没有事务id的，默认为0，creator_trx_id是0。版本链中的以后版本是否能够被以后事务可见的要依据这四个属性依照以下几种状况来判断 当 trx_id = creator_trx_id 时:以后事务能够看见本人所批改的数据， 可见，当 trx_id < min_trx_id 时   : 生成此数据的事务曾经在生成readView前提交了， 可见当  trx_id >= max_trx_id 时   :表明生成该数据的事务是在生成ReadView后才开启的， 不可见当  min_trx_id <= trx_id < max_trx_id 时trx_id 在 m_ids 列表外面 ：生成ReadView时，沉闷事务还未提交，不可见trx_id 不在 m_ids 列表外面 ：事务在生成readView前曾经提交了，可见 ...

大家好，我是公众号：java小杰要加油，明天来分享一个对于mysql的知识点——mysql中的锁话不多说，间接开车事务并发拜访状况读-读 状况并发事务读取雷同的数据，并不会对数据造成影响，容许并发读写-写 状况多事务并发写写时会产生脏写的状况，不过任何一个事务隔离级别都不容许此状况产生，通过加锁来杜绝脏写脏写事务T1 将数据改成了A,然而还未提交，可此时事务T2又将数据改成了B，笼罩了事务T1的更改，T1更新失落，这种状况叫做脏写加锁例如，当初事务T1,T2对这条记录进行并发更改，方才说是隔离级别是通过加锁来杜绝此脏写的，流程如下这个锁构造中有两个比拟要害的信息（其实还有很多信息，前面再聊） trx信息：示意这个锁构造是和哪个事务所关联的is_waiting信息：示意以后事务是否正在期待Q： 能形容一下两个事务并发批改同一条数据时，mysql这个锁是怎么防止脏写的吗？ A ：事务T1在更改这条数据前，就先内存中生成一把锁与此数据相关联（is_waiting为false,代表没有期待），而后咔咔一顿操作更改数据，这个时候，事务T2来了，发现此记录曾经有一把锁与之相关联了（就是T1那一把锁），而后就开始期待（is_waiting为true代表正在期待），事务T1更改完数据提交事务后，就会把此事务对应的所构造开释掉，而后检测一下还有没有与此记录相关联的锁，后果发现T2还在苦苦的期待，就把T2的锁构造的（is_waiting为false,代表没有期待）而后把T2事务对应的线程唤醒，T2获取锁胜利继续执行，总体流程如上。 读-写 /写-读 状况在读-写 / 写 -读的状况下会呈现脏读，不可反复读，幻读的景象，不同的隔离级别能够防止不同的问题，具体相干内容能够看小杰的这篇文章 京东面试官问我：“聊聊MySql事务,MVCC？” 不过贴心的我还是列出来了 注：√代表可能产生，×代表不可能产生 隔离级别脏读不可反复读幻读读未提交（read uncommitted RU）√√√读提交（read committed RC）×√√可反复读（repeatable read RR）××√串行化（serializable ）×××然而 RR在某些水平上防止了幻读的产生 怎么防止脏读、不可反复读、幻读这些景象呢？其实有两种计划 计划一 ：读操作应用MVCC，写操作进行加锁mvcc外面最重要的莫过于ReadView了，它的存在保障了事务不能够读取到未提交的事务所作的更改，防止了脏读。在RC隔离级别下，每次select读操作都会生成ReadView在RR隔离级别下，只有第一次select读操作才会生成ReadView，之后的select读操作都复用这一个ReadView计划二：读写操作都用加锁某些业务场景不容许读取旧记录的值，每次读取都要读取最新的值。例如银行取款事务中，先把余额读取进去，再对余额进行操作。当这个事务在读取余额时，不容许其余事务对此余额进行拜访读取，直到取款事务完结后才能够拜访余额。所以在读数据的时候也要加锁锁分类当应用读写都加锁这个计划来防止并发事务写-写、读-写、写-读时而产生的脏读，不可反复读，幻读景象时，那么这个锁它就要做到，读读时不相互影响，下面三种状况时要互相阻塞，这时锁也分了好几类，咱们持续往下看锁定读共享锁（Shared Lock）：简称S锁，在事务要读取一条记录时，须要先获取该记录的S锁独占锁（Exclusive Lock）：简称X锁，也称排他锁，在事务要改变一条记录时，须要先获取该记录的X锁他们之间兼容关系如下 √代表能够兼容，×代表不可兼容 兼容性S锁X锁S锁√×X锁××事务T1获取某记录的S锁后，事务T2也能够获取此记录的S锁，(兼容)事务T2不能够获取此记录的X锁，直到T1提交后将S锁开释 (不兼容)事务T1获取某记录的X锁后，事务T2不能够获取此记录的S锁，直到T1提交后将X锁开释 (不兼容)事务T2不能够获取此记录的X锁，直到T1提交后将X锁开释 (不兼容)锁定读语句SELECT .. LOCK IN SHARE MODE # 对读取的记录增加S锁SELECT .. FOR UPDATE # 对读取的记录增加X锁多粒度锁后面提到的锁都是针对记录的，其实一个事务也能够在表级进行加锁（S锁、X锁） T1给表加了S锁，那么T2能够持续获取此表的S锁T2能够持续获取此表中的某些记录的S锁T2不能够持续获取此表的X锁T2不能够持续获取此表中的某些记录的X锁T1给表加了X锁，那么T2不能够持续获取此表的S锁T2不能够持续获取此表中的某些记录的S锁T2不能够持续获取此表的X锁T2不能够持续获取此表中的某些记录的X锁可是怎么可能平白无故的就给表加锁呢，难道没什么条件吗？答案是必定有条件的 若想给表加S锁，得先确保表中记录没有X锁若想给表加X锁，得先确保表中记录没有X锁和S锁然而这个怎么确保呢？难道要一行一行的遍历表中的所有数据吗？当然不是啦，聪慧的大佬们想出了上面这两把锁 动向共享锁（Intention Shared Lock）:简称IS锁，当事务筹备在某记录上加S锁时，须要先在表级别加上一个IS锁动向独占锁（Intention Exclusive Lock）:简称IX锁，当事务筹备在某记录上加X锁时，须要先在表级别加上一个IX锁让咱们来看下加上这两把锁之后的成果是什么样子的 当想给记录加S锁时，先给表加一个IS锁，而后再给记录加S锁 当想给记录加X锁时，先给表加IX锁，而后再给记录加X锁 而后 通过下面的操作之后 如果想给表加S锁，先看下表加没加IX锁，如果有的话，则表明此表中的记录有X锁，则须要等到IX锁开释掉后才能够加S锁 如果想给表加X锁，先看下表加没加IS锁或者IX锁，如果有的话，则表明此表中的记录有S锁或者X锁，则须要等到IS锁或者IX锁开释掉后才能够加X锁 这几种锁的兼容性如下表 兼容性IS锁(表级锁)S锁IX锁(表级锁)X锁IS锁(表级锁)√√√×S锁√√××IX锁(表级锁)√×√×X锁××××IS、IX锁都是表级锁，他们能够共存。他们的提出仅仅是为了在之后加表级别的S锁或者X锁时能够疾速判断表中的记录是否被上锁，防止用遍历的形式来查看一行一行的去查看而已InnoDB中的行级锁Record Lock（记录锁）官网名字 LOCK_REC_NOT_GAP仅仅锁住一条记录有S型和X型之分Gap Lock（间隙锁）官网名字 LOCK_GAP给某记录加此锁后，阻塞数据在此记录和上一个记录的间隙插入，然而不锁定此记录有S型和X型之分，可是并没有什么区别他们的作用是雷同的，gap锁的作用仅仅是为了避免插入幻影记录而已，如果对一条记录加了gap锁（无论S/X型）并不会限度其余事务对这条记录加Record Lock或者Gap LockNext-Key Lock(记录锁+间隙锁)官网名字 LOCK_ORDINARY既能够锁住某条记录，又能够组织其余事务在该记录背后插入新记录Insert Intention Lock(插入意向锁锁)官网名字 LOCK_INSERT_INTENTION事务在插入记录时，如果插入的中央加了gap锁，那么此事务须要期待，此时此事务在期待时也须要生成一个锁构造，就是插入意向锁锁内存构造咱们难道锁一条记录就要生成一个锁构造吗？当然不是！一个锁构造如果被加锁的记录合乎上面四条状态的话，那么这些记录的锁则会合到一个锁构造中 ...

前言嗨喽，大家好，我是CrazyCodes, 近一年写的文章，都是一些广度方面的思考，新的一年，在技术深度上也须要有更多的摸索，感激各位的继续反对！ MySQL 先聊聊大家熟知的MySQL,咱们应用MySQL必定是有数据存储的需要。 咱们从根底开始看，首先咱们创立一张用户表 CREATE TABLE `user` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `name` varchar(32) COLLATE utf8mb4_general_ci DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;这是一张简略的用户表，蕴含id和name两个字段，id为主键自增，name上没有索引。想必大家对索引都有肯定的意识，索引是一种数据结构，即本篇的外围议题“树”构造，索引能够达到疾速命中某条记录，“疾速”一词代表着在工夫和空间相结合的最优解，当然也并不代表索引越多，数据表设计越正当，要依据理论业务去抉择。 咱们随机向表中插入几条记录 INSERT INTO `user` VALUES(1,"Join");INSERT INTO `user` VALUES(2,"Tom");INSERT INTO `user` VALUES(3,"Jeein");依照预期，数据库内呈现三条对应的记录，这里我应用语句 SELECT * FROM `user`;对数据进行查问看到这里，你可能说了，这是在讲什么，增删改查都是常识，有什么好讲的，那咱们当初就正式进入正题，首先从插入记录开始说起，MySQL会应用B+树来存储数据记录，B+树是B树的延长，而B树又是均衡二叉树的延长，除了均衡二叉树还有二叉查找树，顺次基于其概念延长的排序，大略是如下这样 B+树 -> B树 -> 均衡二叉树 -> 二叉查找树 -> 二叉树 -> 树当然也不仅仅是所有跟树无关的数据结构，这里为了进步学习树这种数据结构的趣味，所以以MySQL讲起，纠其本源，再联合MySQL的数据记录将这一串常识链接起来，那咱们把这个程序倒过去顺次讲起 树 -> 二叉树 -> 二叉查找树 -> 均衡二叉树 -> B树 -> B+树我尽量不把这些数据结构讲成教科书的样子。 树????你要不晓得树是什么玩意，就别持续看上来了????，就是大巷上咱们看到的树，大巷的树也就是咱们常识认知的树，是通过“树根”、“树枝”和“树叶”组成，缺一样，这树也不是一颗残缺的树。 那么数据结构中的树指的什么，你能够把手机或者电脑倒过去看上图，数据结构中的树，就是一个倒过去的树，并不是他非要倒过去能力说，而是依据人类失常的视觉与思维，就例如你看书总不能从最初一页的最初一个字开始从后往前读把，倒过去只是便于了解和浏览它罢了。 在数据结构中倒过去的树大略是张上面这个样子 ...

数据库主键为什么要用递增的序列？程序的ID占用的空间比随机ID占用的空间小。起因是数据库主键和索引索引应用B+树的数据结构进行存储，程序ID数据存储在最初一个节点的最初的地位，后面的节点数据都是满的。随机ID存储时可能会呈现节点决裂，导致节点多了，然而每个节点的数据量少了，存储到文件系统中时，无论节点中数据是不是满的都会占用一页的空间。所以所导致空间占用较大。 作为主键的要求程序惟一能短则短，缩小空间占用自增的ID能够满足大部分业务场景，然而在一些非凡场景中并不适合，只举局部例子 分布式系统中分库分表的数据库设计存在一些平安问题，对于一些敏感信息容易被揣测。UUID为什么不适宜做主键？UUID值由本机Mac地址和工夫戳等因素决定，UUID呈现反复概率极简直能够忽略不计。 如果需要是只保障唯一性，那么UUID也是能够应用的，然而依照下面的分布式id的要求， UUID其实是不能做成分布式id的，起因如下： 首先分布式id个别都会作为主键，然而mysql官网举荐主键要尽量越短越好，UUID每一个都很长，所以不是很举荐既然分布式id是主键，而后主键是蕴含索引的，而后mysql的索引是通过b+树来实现的，每一次新的UUID数据的插入，为了查问的优化，都会对索引底层的b+树进行批改，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键地城的b+树进行很大的批改，这一点很不好信息不平安：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个破绽曾被用于寻找梅丽莎病毒的制作者地位。Java中的UUIDpackage com.one.util;import java.util.UUID;public class Test { public static void main(String[] args) { String uuid= UUID.randomUUID().toString().replace("-", "").toLowerCase(); System.out.println("UUID的值是:"+uuid); }}

应用阐明column_name DECIMAL(P,D);P是示意有效数字的精度。 P范畴为 1-65。D是示意小数点后的位数。 D的范畴是 0-30。DECIMAL类型也具备UNSIGNED和ZEROFILL属性，如果应用ZEROFILL属性，MySQL会主动将UNSIGNED属性同时增加到列。 应用示例amount DECIMAL(6,2) NOT NULL;在此示例中，amount 列最多能够存储 6 位数字，小数位数为 2 位；因而，amount列的范畴是从-9999.99到9999.99。 -- 公认会计准则(GAAP)规定amount DECIMAL(19,4) NOT NULL;异样解决当数值在字段取值范畴之内，小数位多了则四舍五入后间接截断多出的小数位。 当数值在字段取值范畴之外，则间接报Out of range value谬误。

sql执行计划计算mysql底层会对sql进行查问优化，根据各个计划所产生的cost成本计算最优执行计划，sql的最终执行计划是否走了索引，抑或为什么没有走索引的起因能够用trace工具来剖析。开启trace： mysql> set session optimizer_trace="enabled=on",end_markers_in_json=on; ‐‐开启tracemysql> select * from user where name > 'a' order by age;mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;查看trace字段： 6 {7 "steps": [8 {9 "join_preparation": { ‐‐第一阶段：SQL筹备阶段，格式化sql10 "select#": 1,11 "steps": [12 {13 "expanded_query": "/* select#1 */ select `employees`.`id` AS `id`,`employees`.`name` AS `name`,`employees`.`age` AS `age`,`employees`.`position` AS `position`,`employees`.`hire_time` AS `hire_time` from`employees` where (`employees`.`name` > 'a') order by `employees`.`position`"14 }15 ] /* steps */16 } /* join_preparation */17 },18 {19 "join_optimization": { ‐‐第二阶段：SQL优化阶段20 "select#": 1,21 "steps": [22 {23 "condition_processing": { ‐‐条件解决24 "condition": "WHERE",25 "original_condition": "(`employees`.`name` > 'a')",26 "steps": [27 {28 "transformation": "equality_propagation",29 "resulting_condition": "(`employees`.`name` > 'a')"30 },31 {32 "transformation": "constant_propagation",33 "resulting_condition": "(`employees`.`name` > 'a')"34 },35 {36 "transformation": "trivial_condition_removal",37 "resulting_condition": "(`employees`.`name` > 'a')"38 }39 ] /* steps */40 } /* condition_processing */41 },42 {43 "substitute_generated_columns": {44 } /* substitute_generated_columns */45 },46 {47 "table_dependencies": [ ‐‐表依赖详情48 {49 "table": "`employees`",50 "row_may_be_null": false,51 "map_bit": 0,52 "depends_on_map_bits": [53 ] /* depends_on_map_bits */54 }55 ] /* table_dependencies */56 },57 {58 "ref_optimizer_key_uses": [59 ] /* ref_optimizer_key_uses */60 },61 {62 "rows_estimation": [ ‐‐预估表的拜访老本63 {64 "table": "`employees`",65 "range_analysis": {66 "table_scan": { ‐‐全表扫描状况67 "rows": 10123, ‐‐扫描行数68 "cost": 2054.7 ‐‐查问老本69 } /* table_scan */,70 "potential_range_indexes": [ ‐‐查问可能应用的索引71 {72 "index": "PRIMARY", ‐‐主键索引73 "usable": false,74 "cause": "not_applicable"75 },76 {77 "index": "idx_name_age_position", ‐‐辅助索引78 "usable": true,79 "key_parts": [80 "name",81 "age",82 "position",83 "id"84 ] /* key_parts */85 }86 ] /* potential_range_indexes */,87 "setup_range_conditions": [88 ] /* setup_range_conditions */,89 "group_index_range": {90 "chosen": false,91 "cause": "not_group_by_or_distinct"92 } /* group_index_range */,93 "analyzing_range_alternatives": { ‐‐剖析各个索引应用老本94 "range_scan_alternatives": [95 {96 "index": "idx_name_age_position",97 "ranges": [98 "a < name" ‐‐索引应用范畴99 ] /* ranges */,100 "index_dives_for_eq_ranges": true,101 "rowid_ordered": false, ‐‐应用该索引获取的记录是否依照主键排序102 "using_mrr": false,103 "index_only": false, ‐‐是否应用笼罩索引104 "rows": 5061, ‐‐索引扫描行数105 "cost": 6074.2, ‐‐索引应用老本106 "chosen": false, ‐‐是否抉择该索引107 "cause": "cost"108 }109 ] /* range_scan_alternatives */,110 "analyzing_roworder_intersect": {111 "usable": false,112 "cause": "too_few_roworder_scans"113 } /* analyzing_roworder_intersect */114 } /* analyzing_range_alternatives */115 } /* range_analysis */116 }117 ] /* rows_estimation */118 },119 {120 "considered_execution_plans": [121 {122 "plan_prefix": [123 ] /* plan_prefix */,124 "table": "`employees`",125 "best_access_path": { ‐‐最优拜访门路126 "considered_access_paths": [ ‐‐最终抉择的拜访门路127 {128 "rows_to_scan": 10123,129 "access_type": "scan", ‐‐拜访类型：为scan，全表扫描130 "resulting_rows": 10123,131 "cost": 2052.6,132 "chosen": true, ‐‐确定抉择133 "use_tmp_table": true134 }135 ] /* considered_access_paths */136 } /* best_access_path */,137 "condition_filtering_pct": 100,138 "rows_for_plan": 10123,139 "cost_for_plan": 2052.6,140 "sort_cost": 10123,141 "new_cost_for_plan": 12176,142 "chosen": true143 }144 ] /* considered_execution_plans */145 },146 {147 "attaching_conditions_to_tables": {148 "original_condition": "(`employees`.`name` > 'a')",149 "attached_conditions_computation": [150 ] /* attached_conditions_computation */,151 "attached_conditions_summary": [152 {153 "table": "`employees`",154 "attached": "(`employees`.`name` > 'a')"155 }156 ] /* attached_conditions_summary */157 } /* attaching_conditions_to_tables */158 },159 {160 "clause_processing": {161 "clause": "ORDER BY",162 "original_clause": "`employees`.`position`",163 "items": [164 {165 "item": "`employees`.`position`"166 }167 ] /* items */,168 "resulting_clause_is_simple": true,169 "resulting_clause": "`employees`.`position`"170 } /* clause_processing */171 },172 {173 "reconsidering_access_paths_for_index_ordering": {174 "clause": "ORDER BY",175 "steps": [176 ] /* steps */,177 "index_order_summary": {178 "table": "`employees`",179 "index_provides_order": false,180 "order_direction": "undefined",181 "index": "unknown",182 "plan_changed": false183 } /* index_order_summary */184 } /* reconsidering_access_paths_for_index_ordering */185 },186 {187 "refine_plan": [188 {189 "table": "`employees`"190 }191 ] /* refine_plan */192 }193 ] /* steps */194 } /* join_optimization */195 },196 {197 "join_execution": { ‐‐第三阶段：SQL执行阶段198 "select#": 1,199 "steps": [200 ] /* steps */201 } /* join_execution */202 }203 ] /* steps */204 }205206 论断：全表扫描的老本低于索引扫描，所以mysql最终抉择全表扫描207208 mysql> select * from employees where name > 'zzz' order by position;209 mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE;210211 查看trace字段可知索引扫描的老本低于全表扫描，所以mysql最终抉择索引扫描212（↑↑↑援用↑↑↑） ...

开源数据库只是随其源代码一起散发的惯例数据库。 用户能够自在地浏览、批改和扩大软件。对于许多人来说，最有吸引力的个性可能是它能够在任何时候在任何中央的任何硬件上运行它。源代码是所有程序员都能够依据本人的须要应用的公共资源。 什么是开源数据库并不是说架构、语言或者定义开源数据库的个性集有什么不同。事实上，许多开源选项就像它们的专有版本一样应用 SQL 版本。 对于与专有软件供应商从新受权会谈的管理人员来说，许可始终很有吸引力。如果源代码不被共享，他们惟一的抉择就是转移到另一个产品，这通常包含大量的重写。 然而，天下没有收费的午餐。这些源代码或者也存在一些“陷阱”，有些比拟显著有些则是暗藏起来的。许多开源许可证中，有些对用户简直没有任何限度，有些则保持要求用户共享任何加强，从根本上确保公共代码对所有人放弃凋谢。 另一个没有明确阐明但对用户来说十分重要的就是，必须有人付钱给开发人员。 一些应用开放源码数据库的公司会雇人为代码库做奉献。他们不是购买专有许可证，而是通过向开发人员领取薪水。抉择这种形式的公司偏向于他们对所取得的代码库的管制。 许多开源数据库是在混合模式下公布的。有些人会创立两个不同的版本，其中更简略、更通用的代码能够被称为“社区版”，并且能够自在公布。摸索该技术并创立新原型的开发人员能够收费下载它。 反对开发的公司的账单通常由逐步采纳”商业版本”的公司领取，这种版本通常提供与解决较大数据集或提供更好的安全性无关的额定性能。它们通常是新开发人员不须要的个性，然而对于运行生产代码的团队来说，它们提供了长期的价值。设置多个版本并确保每个版本都有正确的个性是一门艺术。在商业版中保留太多的性能，没有人会去尝试。在社区版中留下太多，没有人会感觉须要降级和付费。 开放源码数据库能够分为很多类别，这些类别在很大水平上取决于它们的倒退时代。最早的工具，如 MySQL 或 PostgreSQL，仿效了商业首领。它们应用 SQL 语言，并将数据存储在按索引排序、由 JOIN 例程链接的关系表中。有时它们并不提供同样残缺的个性抉择，然而它们逐步进化到反对雷同的数据存储格调。 起初的 NoSQL 数据库，如 MongoDB 和 Cassandra，以其灵便的模式和文档格调的键值对存储而闻名。这种非凡类型的数据库在很大水平上演变为开放源码。 一些最新的数据库，比方那些反对分类账或天文数据的数据库，通常是几对产品的混合体。一个是收费提供的功能齐全的社区版本。另一个通常被称为“企业版”，因为它蕴含的个性反对更大的数据集，而这些数据集可能须要更高的稳定性和可靠性。这些额定的性能通常只有在付费的状况下能力应用。 次要供应商是如何承受开源的甲骨文在 2009 年收买 Sun Microsystems 的过程中收买了 MySQL，无效地意识到了开源模式的力量，于是他们持续开发和反对数据库。用户能够抉择免费版，也就是所谓的社区版，也能够抉择更高级的版本，其中蕴含大公司所需的额定性能。其中，备份、额定的安全性和集群治理是须要付费的。 甲骨文还收买了 BerkeleyDB，这是一组经常被编译成程序的键值数据库。它们使开发人员能够加重保护数据结构的工作。 微软曾经抉择在 Azure 云上托管一些次要的开源数据库。心愿依赖 PostgreSQL 或 MySQL 的团队能够启动由微软治理的实例，从而省去配置和保护服务器的麻烦。 其余云供应商也在遵循相似的门路，亚马逊、谷歌、DigitalOcean、Rackspace 和其余几家公司都提供了租用全配置服务器的抉择，这些服务器都有支流开源数据库的运行版本。亚马逊单独提供了大多数次要开源数据库的托管版本。 这些托管实例的呈现使一些开发人员感到困扰。许多云计算提供商公布的新产品布告都提供了装置和保护开源软件包的信息。这些不是无关紧要的工作，然而工作能够自动化。这导致了工具开发人员和云公司之间的摩擦，而这些抵触还远未解决。 从开源我的项目开始的新数据库许多新数据库都是从开源我的项目开始的。有数十家新公司依据社区开源许可证公布了新数据库。其中大多数公司还试图通过发售一些反对和额定的专有性能来反对本人。 这些开源我的项目中，有些我的项目建设在以前的版本之上。MariaDB 是 MySQL 的创始人之一 Monty Widenius 发动的 MySQL 的分支。在把 MySQL 卖给甲骨文后，他开始了这个新版本。晚期版本始于原始的代码库，但最新版本减少了一些个性，能够放慢解决极大数据集的速度。SQL 语法的许多根本个性和外围局部是雷同的，所以许多开发人员能够在它们之间自在切换。在将来，这种差别可能还会扩充。例如，MariaDB 曾经减少了与 Cassandra、 TokuDB 和 sphinx 等风行数据库的集成。 SequoiaDB 是一个反对 SQL、键值文档存储和间接 JSON 存储的大型分布式数据库。数据库将各种节点连贯在一起，每个节点可能是不同的存储引擎，如 MySQL 或 PostgreSQL。数据库将查问路由到适当的节点，同时确保事务能够提供 acid 级别的并发性。外围是在 AGPL 下公布的，而有些连接器是由 Apache 许可证治理的。 ...

MySQL中的函数<1> 加密函数password(str) 该函数能够对字符串str进行加密，个别状况下，此函数给用户明码进行加密select password('ruochen666');select PASSWORD(ename) from emp;md5(str) 对字符串str进行散列加密，可用户对于一些一般的不须要解密的数据进行加密select MD5('ruochen666');select MD5(ename) from emp;<2> 聚合函数avg() select avg(sal) from emp; # 均匀薪资count() select count(*) from emp; # 员工数量min() select MIN(sal) from emp; # 最低薪资max() select MAX(sal) from emp; # 最高薪资sum() select SUM(sal) from emp; # 薪资求和<3> 数学相干的函数rand() 返回0～1的随机数select RAND();ads(num) 获取num的绝对值select ABS(-1);mod(num1, num2) 取余数select MOD(10, 3);ceiling(num) 向上取整select CEILING(10.1);floor(num) 向下取整select FLOOR(10.1);round(num) 返回离num最近的数 --- 四舍五入select ROUND(10.4);round(num, n) 保留num小数点后的n位select ROUND(10.12345, 2);least(num, num2 ....) 求最小值select LEAST(10, 5, 11, 23, 54);<4> 字符相干的函数char_length(str) ...

MySql外部组件构造 Server层连接器治理连贯与权限校验连贯数据库时负责监听数据库端口申请的便是连接器。连贯命令如下所示：# mysql ‐h host[数据库地址] ‐u root[用户] ‐p root[明码] ‐P 3306连贯命令中的 mysql 是客户端工具，用来跟服务端建设连贯。在实现经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输出的用户名和明码。1、如果用户名或明码不对，你就会收到一个"Access denied for user"的谬误，而后客户端程序完结执行。2、如果用户名明码认证通过，连接器会到权限表外面查出你领有的权限。之后，这个连贯外面的权限判断逻辑，都将依赖于此时读到的权限。这就意味着，一个用户胜利建设连贯后，权限会缓存在一个seesion中，此时即便你用管理员账号对这个用户的权限做了批改，也不会影响曾经存在连贯的权限。批改实现后，只有再新建的连贯才会应用新的权限设置。用户的权限表在零碎表空间的mysql的user表中。查问缓存一个特地鸡肋的存在，就是把查问后果放在缓存里，下次有同样的sql间接从缓存中取数据，但对缓存数据所关联的表的任何批改都会导致缓存被清空，只有在变动简直没有的动态表有存在价值，8.0当前的mysql曾经移除了查问缓存语法分析器如果没有命中缓存，那么mysql行将开始剖析输出的sql语句，依据sql语句的关键字和语句构造对sql进行拆分，辨认出SQL的目标。词法分析器分成6个次要步骤实现对sql语句的剖析1、词法剖析2、语法分析3、语义剖析4、结构执行树5、生成执行打算6、打算的执行 SQL语句的剖析分为词法剖析与语法分析，mysql的词法剖析由MySQLLex[MySQL本人实现的]实现，语法分析由Bison生成，通过bison语法分析之后，会生成一个这样的语法树 优化器通过了分析器，MySQL 就晓得你要做什么了。在开始执行之前，还要先通过优化器的解决。优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序。如果有多种计划最终的执行后果是雷同的，那么优化器会抉择一个执行效率更高的计划。执行器优化过后mysql就曾经确定了该sql语句的目标，开始执行过程之前会先进行权限判断，如果权限没有问题则开表执行，否则返回错误信息。执行过程依据表的存储引擎类型去调用引擎提供的接口，例如innoDB等存储引擎。store层mysql的store层比拟罕用的有三种innoDB,Myisam,memorybin-log归档mysql的binlog是Server层实现的二进制日志,他会记录咱们的cud操作，特点如下：1、Binlog在Server层实现（引擎共用）2、Binlog为逻辑日志,记录的是一条语句的原始逻辑3、Binlog不限大小,追加写入,不会笼罩以前的日志误删数据/库,能够应用binlog进行归档复原!但须要先开启MySQL的binlog性能。配置my.cnf开启binloglog‐bin=/usr/local/mysql/data/binlog/mysql‐binbinlog‐format=ROWsync‐binlog=1留神5.7以及更高版本须要配置本项：server‐id=123454（自定义,保障唯一性）; #binlog格局，有3种statement,row,mixed，statement示意存储执行的sql语句，分布式的时候有可能造成数据不统一；row示意存储的是sql执行后最终的数据后果，但会影响效率；mixed是前两种的合体，效率最低。

概述Freedgo 一款弱小的在线ER模型生成的工具，能够针对MySQL,Oracle,SQLServer,PostgreSQL的 DDL文件在线生成ER模型图表。 能够导入导出数据库DDL文件能够生成数据库设计文档反对在线编辑ER模型,反对数据库建表语句,正文性能反对表与表之间的各种关系图反对导入SQL文件创建ER模型，反对create table,alter table。反对主键、外键显示疾速上手工具地址：进入 裕奥在线ER模型设计工具 进行ER模型的设计想要理解更多的工具应用文档请拜访 https://www.freedgo.com/publi...上面次要介绍一下特色性能 主题格调提供四种不同的主题格调 KennedyMinimalAtlasDrak## Minimal 抉择 图表->爱好->主题 能够切换不同的主题. ER模型设计工具提供了模块化的ER模型图,能够各页生成不同模块的ER模型,如:用户模块,商品模块等等 留神在切换之前请保留好数据文件,免得数据失落. ## Kennedy主题格调 ## Atlas主题格调 Drak主题格调 Freedgo Desgin是一款轻松、疾速、合作地创立各种业余图表工具。让您在线创立流程图、零碎部署图、软件架构图、UML、BPMN、在线制图ER模型转word数据库设计文档,DFD,组织图,软件流程图,图表。收费试用。如果你应用ERwin 或者PowerDesign等等传统的客户端工具设计表构造，无妨体验一下在线在线制图ER模型转word数据库设计文档带来的轻量级，云端存储，随时应用的益处。

多表查问1. 表与表之间的关系<1> 一对一用户表和身份信息表，用户表是主表男人表、女人表 create table man( mid int primary key auto_increment,mname varchar(32),wid int unique ); create table woman( wid int primary key auto_increment,wname varchar(32)); <2> 一对多最常见得表关系，用户表和订单表员工表、部门表create table emp( empno int primary key auto_increment,ename varchar(32)deptno int); create teble dept( deptno int primary key auto_increment,dname varchar(32)); <3> 多对多学生表和课程表，通常状况都是将多对多的关系拆分为一对多或者多对一的关系至多须要三张表 create table student( cid int primary key auto_increment,sname varchar(32)); insert into student (sname) values('小张');insert into student (sname) values('小李');insert into student (sname) values('小王'); create table course( ...

Explain工具介绍应用EXPLAIN关键字能够模仿优化器执行SQL语句，剖析你的查问语句或是构造的性能瓶颈在 select 语句之前减少 explain 关键字，MySQL 会在查问上设置一个标记，执行查问会返回执行打算的信息，而不是执行这条SQL e.x explain select * from user where id =2;explain查问后果中的列1.id列 id列是 select 的序列号。id列越大执行优先级越高，id雷同则从上往下执行，id为NULL最初执行。2.select_type列 select_type 示意该行对应的查问块是简略还是简单的查问。1）simple：简略查问。查问不蕴含子查问和union2）primary：简单查问中最外层的 select3）subquery：蕴含在 select 中的子查问（不在 from 子句中）4）derived：蕴含在 from 子句中的子查问。MySQL会将后果寄存在一个长期表中，也称为派生表（derived的英文含意）5）union：在 union 中的第二个和随后的 select3.table列 这一列示意 explain 的一行正在拜访哪个表。当 from 子句中有子查问时，table列是 <derivenN> 格局，示意以后查问依赖 id=N 的查问，于是先执行 id=N 的查问。4.type列 这一列示意关联类型或拜访类型，即MySQL决定如何查找表中的行，查找数据行记录的大略范畴。顺次从最优到最差别离为：system > const > eq_ref > ref > range > index > ALL一般来说，得保障查问达到range级别，最好达到ref**NULL**：mysql可能在优化阶段合成查问语句，在执行阶段用不着再拜访表或索引。例如：在索引列中选取最小值，能够独自查找索引来实现，不须要在执行时拜访表**const, system**：mysql能对查问的某局部进行优化并将其转化成一个常量（能够看show warnings 的后果）。用于primary key 或 unique key 的所有列与常数比拟时，所以表最多有一个匹配行，读取1次，速度比拟快。system是const的特例，表里只有一条元组匹配时为system**eq_ref**：primary key 或 unique key 索引的所有局部被连贯应用 ，最多只会返回一条符合条件的记录。这可能是在const 之外最好的联接类型了，简略的 select 查问不会呈现这种 type。**ref**：相比 eq_ref，不应用惟一索引，而是应用一般索引或者唯一性索引的局部前缀，索引要和某个值相比拟，可能会找到多个符合条件的行。**index**：扫描全索引就能拿到后果，个别是扫描某个二级索引，这种扫描不会从索引树根节点开始疾速查找，而是间接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查问个别为应用笼罩索引，二级索引个别比拟小，所以这种通常比ALL快一些。**ALL**：即全表扫描，扫描你的聚簇索引的所有叶子节点。通常状况下这须要减少索引来进行优化了。5.possible_keys列 ...

MySQL束缚<1> 概念是一种限度，它是对表的行和列的数据做出束缚，确保表中数据的完整性和唯一性。<2> 应用场景创立表的时候，增加束缚<3> 分类default: 默认束缚, 域完整性not null: 非空束缚，域完整性unique: 惟一束缚，实体完整性primary key: 主键束缚，实体完整性foreign key: 外键束缚，参照完整性check: 查看束缚（MySQL不反对），域完整性auto_increment: 自增长束缚unsigned: 无符号束缚zerofill: 零填充束缚数据库中有三个完整性: 域、实体、参照完整性 域(列)完整性： 域完整性是对数据表中字段属性的束缚实体完整性在MySQL中实现： 通过主键束缚和候选键束缚实现的参照完整性： 也就是说是MySQL的外键1. default概念 指定某列的默认值，插入数据时候，此列没有值，则用default指定的值来填充增加 在创立表的时候增加： create .... default create table t1(       id int default 1,       name varchar(20) default '老王' ); 通过alter语句增加： alter .... modify/change .... alter table t1 modify id int default 2;alter table t1 change name name varchar(20) default '若尘';删除 alter .... modify/changealter table t1 modify id int;alter table t1 change name name varchar(20);2. not null概念 ...

索引数据结构1、 二叉搜寻树（Binary Search Tree） 二叉搜寻树是每个节点最多有两个子节点的树，依照右侧子节点大于本节点，左侧子节点小于本节点的法则排列，能够用作搜寻，构造如下图所示 二叉树尽管能够用于查找，但在某种特定状况下查找效率并不高，相似于下图： 2、红黑树 对于二叉树的毛病，红黑树是一种领有自均衡属性的二叉树，红黑树有五个个性： 每个结点是彩色或者红色。根结点是彩色。每个叶子结点（NIL）是彩色。 [留神：这里叶子结点，是指为空(NIL或NULL)的叶子结点！不是有值的最初一个节点。]不能有两个相连的红色节点。每个结点到叶子结点NIL所通过的彩色结点的个数一样的。依据以上五种属性，红黑树生成时采纳左旋，右旋，左右旋，右坐旋等才做，会生成出一颗绝对均衡的二叉树，如下图 3、Hash表 Hash表相似于java中的hashMap，把索引列做hash映射后以KV构造存储在内存中，是精准查找最快的索引构造，只须要一次hash便能够定位，但不反对范畴查找。就是个K-V构造，不画图了4、B-Tree 因为数据库要存储大量的数据，如果采纳二叉树进行查找，数据量过大时二叉树的层级过多，须要由上到下进行查找效率过慢，所以呈现了B-Tree，BTree有如下特色·叶节点具备雷同的深度·叶节点的指针为空·所有索引元素不反复·节点中的数据索引从左到右递增排列数据结构间接上图 5、B+Tree 不过mysql真正采纳的不是BTree，Btree在做索引的时候有些中央并不是很实用，最终优化出了B+tree作为mysql innoDB存储类型的索引，B+tree的特色如下 非叶子节点不存储data，只存储索引(冗余)能够放更多的索引叶子节点蕴含所有索引字段叶子节点用指针连贯，进步区间拜访的性能构造如下图 PS：innoDB中的主键索引的B+tree是汇集索引，叶子结点间接存储的其余字段的值，用于缩小IO的次数，而辅助索引的叶子结点则是存储的主键的值，用于辅助查找mysql次要索引类型1：MyISAM存储引擎索引实 MyISAM的索引和数据文件是离开的（非汇集索引），索引的叶子节点存储的是数据的物理地址，查找到相干索引后再用索引去硬盘上查找数据2：InnoDB存储引擎索引实现 InnoDB的索引是和数据存储在一起的（汇集索引），叶子结点中存储了所有其余字段的值，只须要一次加载叶子结点的IO进行索引匹配，匹配胜利后不须要再次进行IO操作读取对应的数据--表数据文件自身就是按B+Tree组织的一个索引构造文件--非主键索引构造叶子节点存储主键值的起因是为了一致性和节俭存储空间3： 联结索引的底层存储构造 联结索引是依据索引建设时字段的排列程序建设的索引，后续索引是对第一个字段索引的再划分，差找时如果不能保障依照索引简历时的程序进行查问，则联结索引生效

一、 数据查询语言(DQL)(重中之重)残缺语法格局： select 表达式1|字段,....[from 表名 where 条件][group by 列名][having 条件][order by 列名 [asc|desc]][limit 地位,数量]<1> 一般查问select 查问表达式; // 最简略的sql语句，是一个函数select database();select version();select now();<2> 条件查问where 条件表达式, 反对运算符和函数MySQL反对的运算符： =、 !=、 >、 >=、 <、 <=、 <>and、 or、 notis null、 is not nullbetween...and... （区间查问，多少到多少之间）in(set);like 通配符和占位符: % _ （含糊查问） %: 示意0个或者多个字符_: 示意占位一个-- 查问所有的老师信息 select * from teacher;-- 查问id 大于2的老师信息 select * from teacher where id>2; -- 查问姓名为空的老师信息 在数据库中null永远都不等于null，那么怎么去判断null值？通过 is null / is not null-- select * from teacher where name=null; # 谬误 select * from teacher where name is not null;-- 查问id为1 并且 姓名是 "xiaosi"的老师信息 select * from teacher where id=1 and name='xiaosi';-- 查问id为1 并且 姓名是 "xiaosi"的老师信息 select * from teacher where id=1 or name='xiaosi';-- 查问薪水在2000到10000之间的老师信息 select * from teacher where sal >=2000 and sal <=10000; select * from teacher where sal between 2000 and 10000; # 这种形式等同于下面-- 查问姓名中有 ‘尘’ 字的老师信息 select * from teacher where name like '%尘%';-- 查问姓名是三个字的 select * from teacher where name like '___';-- 查问姓 '小' 的老师信息 select * from teacher where name like '小%';-- 查问名字中含有下划线的老师信息 '\' 本义-- select * from teacher where name like '%_%'; # 谬误 select * from teacher where name like '%\_%'; <3> 分组查问语法格局： ...

一、MySQL数据库数据类型<1> MySQL数据库中反对多种数据类型数值型字符型日期型<2> 罕用的数据类型整型 int：整型，存储整数int(M): M示意预期值，与存储大小和数值的范畴无关 id int                    1id int(3) zerofill 001zerofill 零填充 会在左侧补0tinyint         1        -128～127smallint       2        32767/65535int               4        21亿bigint           8        兆mediumint    3        八百多万/一千六百多万浮点型 float[(M,D)]: 浮点型，存储小数 salary float(6,2): 示意最多6位，小数占2位，最大存储数值为：9999.99double: 浮点型，小数字符型 char(M): 固定长度的字符串类型          name char(5)      '1     'varchar(M): 可变长度的字符串类型 (举荐)   name varchar(5) '1'text: 大的字符串类型，4G字符串blob：字节类型日期 date: 日期类型，年月日 YYYY-MM-DD 日期格局time: 工夫类型，时分秒 HH：mm：ss 工夫格局year: 年份，年               YYYY格局的年份值timestamp: 年月日 时分秒，工夫戳 1970年1月1日0时0分0秒 - 2037年的某一个时刻   YYYYMMDDhhmmssdatetime: 年月日 时分秒  YY-MM-DD hh：mm：ss留神：抉择适合的数据类型，是数据库优化的一部分，short it better 准则二、MySQL数据库中的数据的应用如何操作：编程语言<1> SQL概述结构化查询语言，能够用于查问和批改关系数据库的语言SQL语言，是数据库的外围语言，被ISO驳回为数据库语言国际标准，简直所有的数据库都反对SQL<2> 组成数据定义语言(Data Definition Language, DDL): 用于治理和定义数据对象，包含数据库，数据表等 create: 创立数据库和表drop: 删除表对象alter: 批改表构造数据操作语言(Data Manipulation Language, DML): 用于操作数据库对象中所蕴含的数据 insert: 增加数据delete: 删除数据update: 批改数据数据查询语言(Data Query Language, DQL): 用于查询数据库对象中所蕴含的数据 ...

环境unbuntu 20.04mariaDBzabbix装置教程https://www.zabbix.com/cn/dow... 在装置zabbix的时候,导入初始架构和数据，sql呈现了问题 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.谬误是sql行大小过小为了解决这个问题，我找到了sql的设置文件 /etc/mysql/my.cnfvim退出以下指令 [mysqld]max_allowed_packet = 1Ginnodb_log_file_size = 2Ginnodb_log_buffer_size = 512M 之后再应用 # zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix会显示用户和database已存在 Table 'users' already exists所以删除数据库中的database和用户 MariaDB [(none)]> DROP USER 'zabbix'@'localhost';MariaDB [(none)]> DROP DATABASE zabbix;从新链接数据库和zabbix (集体还未了解为什么zabbix须要数据库，但愿有人能解答我的纳闷) mysql -uroot -ppasswordmysql> create database zabbix character set utf8 collate utf8_bin;mysql> create user zabbix@localhost identified by 'password';mysql> grant all privileges on zabbix.* to zabbix@localhost;mysql> quit;zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix`而后重启一下就ok了 ...

MySQL数据库概要一、 MySQL数据库的概述二、 MySQL数据库的搭建(重点)三、 MySQL数据库软件的应用四、 MySQL数据类型五、 MySQL数据库数据的操作(重点) 一、初识MySQL数据库1. 数据库的概述<1> 数据库：Database长期存储在计算机内的，有组织的，可共享的数据汇合。存储数据的仓库。（文件）<2> 数据库管理系统：Database Management System操纵和治理数据库的软件。（软件）<3> 数据库的类型关系型数据库：二维表的模式存储数据。非关系型数据库：NoSQL---------Not only SQL Redis：键值对存储，K-V模式存储MongoDB：文档存储，将数据以文档的模式存储，Json/XMLHBase：列存储，Hadoop Database<4> 支流的关系型数据库Oracle：甲骨文公司SQLServer：微软 简略、界面敌对，交互和操作性更强开放性差，性能低DB2：IBM 伸缩性比拟强，实用所有的支流的平台免费MySQL：MySQL AB2. MySQL数据库概述<1> MySQL数据库MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发的，目前属于Oracle旗下产品。<2> 版本社区版：收费(集体、组织、企业)企业版：非盈利的版权，会收取肯定的服务费<3> 特点开源、自在的关系型数据库管理系统短小精悍，速度快，领有成本低是 LAMP 风行的网站架构的一部分(Linux+Apache+MySQL+php)被宽泛的使用在互联网公司中(中小型网站中)二、装置 MySQL数据库<1> 装置形式ZIP装置，压缩包的形式装置MSI装置：windows installer 微软格局的安装包装置<2> 注意事项：以前装置过，须要卸载洁净再装置敞开MySQL服务 右击计算机，点击治理，找到mysql服务敞开卸载MySQL软件 控制面板----程序----卸载程序----右键卸载MySQLxxx文件删除残留文件 原装置地位删除c:\ProgramData\MySQL删除残留文件配置参数 关上注册表(win+R----regedit----xxxMACHINE----SYSTEM----ControlSetxxx----Services----EventLog----Application----删除MySQLxxx)<3> 装置MSI装置形式(操作和配置更加简略)留神：字符集的抉择，举荐utf8三、应用MySQL软件<1> 启动服务net start mysql 启动服务net stop mysql 敞开服务<2> 登陆数据库格局：mysql -参数参数： -u 用户名-p 明码-P 端口号-h 数据库的服务器地址(近程链接数据库)-- prompt 设置提示符例如： mysql -uroot -prootmysql -uroot -proot -P3306 -h127.0.0.1mysql -uroot -proot -P3306 -h123.231.11.35(阿里云上的服务器: 上海|北京)mysql -uroot -p回车 明码(明码不可见)应用MySQL Command Line Clinet 输出明码<3> 退出数据库ctrl+cexit\qquit<4> 批改明码第一种批改明码形式，当你遗记m明码的时候应用这种形式批改 ...

档次数据结构的数据表设计存储树形构造数据是一个常见的问题，同时也有多种解决方案。 这里介绍三种树形构造的表设计方案： 邻接表模型基于门路和层级的表设计基于左右值编码的表设计（MPT）这里以一个在线食品店作为例子，食品通过类别、色彩和种类组织食品。 示例如下： 一、邻接表模型最简略的办法就是应用邻接表模型或者叫做递归模型。通过显示地形容某一节点的父节点，从而可能建设二维的关系表，你只须要一个简略的函数去迭代查问即可获取你的数据。 示例如下：长处： 设计简略实现容易直观毛病： 因为是递归模型CRUD操作低效二、基于门路和层级的表设计在一的根底上加上一个 level 字段来示意以后节点到根节点的间隔和一个 key 字段来示意搜寻门路。 Node_id 主键Name 名字Parent_id 父节点的idkey 搜寻门路level 示意以后节点到根节点的间隔或者层级示例如下：两种需要查问解决方案如下： 查找d的所有子孙节点：select * from table_name where key like "${d.key}-${d.id}-%"查找某个节点的所有子节点：select * from table_name where key like "${d.key}-${d.id}-%" and level=${d.level}+1此设计构造简略，利用key和level两个辅助字段能够实现查问操作比一更加高效，而且保护这两个字段老本很低。 三、基于左右值编码的表设计(MPT)为了防止对于树形构造查问时的“递归”过程，基于Tree的前序遍历设计一种全新的无递归查问、有限分组的左右值编码方案，来保留该树的数据。如下图所示, 从根节点Food左侧开始，标记为1，并沿前序遍历的方向，顺次在遍历的门路上标注数字，最初咱们回到了根节点Food，并在左边写上了18。 注：lft 和 rgt 别离对应 DFS 的发现工夫 d 和实现工夫雷同 f如果咱们须要查问Fruit的后续节点，只需找出所有左值大于2，并且右值小于11的节点即可。 1. 获取某节点的子孙节点返回某节点子孙节点的前序遍历列表，以Fruit为例： SQL: SELECT* FROM Tree WHERE Lft BETWEEN 2 AND 11 ORDER BY Lft ASC 查问后果如下：那么某个节点到底有多少的子孙节点呢？ 通过该节点的左、右值咱们能够将其子孙节点圈进来，则子孙总数 = (右值 – 左值– 1) / 2，以Fruit为例，其子孙总数为：(11 –2 – 1) / 2 = 4。 ...

明天忽然被共事问到，MySql 里的 uft8 与 utf8mb4 到底有什么区别，过后我也是一脸问号，因而特地去理解了一下。<!-- more --> 字符集uft8 与 utf8mb4 其实指的是 MySQL 中的字符集，那到底什么是字符集呢？ 概念很多人经常会把字符、字符集、字符编码的概念一概而论，明天咱们认真来看看。 何为字符？ 字符（Charcter）是文字与符号的总称，包含文字、图形符号、数学符号等。26个英文字母属于字符，每个汉字也属于一个字符。那么什么叫字符集？ 字符集是一组形象的字符（Charcter）组合的汇合。举一个例子，所有的汉字就算一个“字符汇合”， 所有的英语字母也算一个“字符汇合”。 留神，我这里说它们是字符汇合，而且还有双引号。是因为字符集并不简略的是字符的汇合， 精确概述来说，字符集是一套符号和编码的规定。 字符集须要以某种字符编码方式来示意、存储字符。咱们晓得，计算机外部，所有信息最终都是一个二进制值。每一个二进制位（bit）有0和1两种状态。而如果用不同的0和1组合示意不同的字符就是编码。那什么叫字符编码呢？ 字符最终是以二进制模式存储在磁盘的，这也是为什么要有字符编码的起因，因为计算机最终都要以二进制模式存储，那么编码规定就是用什么样的二进制来代表这个字符。例如，咱们所熟知的ASCII码表中，01000011这个二进制对应的十进制是67，它代表的就是英语字母C。精确概述来说，字符编码方式是用一个或多个字节的二进制模式示意字符集中的一个字符。每种字符集都有本人特有的编码方式，因而同一个字符，在不同字符集的编码方式下，可能会产生不同的二进制模式。既然咱们经晓得了 utf8 与 utf8mb4 都是一种字符集，那两种到底有什么区别呢？ utf8MySQL 在创建时应用的字符集就是 utf8。首先它能存储下大部分的中文汉字，对于咱们失常应用必定是入不敷出的。 它由三个字节组成，能组成的最大 Unicode 字符是0xffff，也就是 Unicode 中的根本多文种立体（BMP）。 也就是说，任何不在根本多文本立体的 Unicode 字符，都无奈应用 MySQL 的 utf8 字符集存储。 utf8mb4MySQL 在5.5.3之后减少了这个utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的 Unicode。 新增的一个字节，能够让它反对包含 Emoji 表情（Emoji 是一种非凡的 Unicode 编码，常见于 ios 和 android 手机上），和很多不罕用的汉字，以及任何新增的 Unicode 字符等等。 应用我感觉，为了获取更好的兼容性，应该总是应用 utf8mb4 而非 utf8。 对于 CHAR 类型数据，utf8mb4 会多耗费一些空间，依据 MySQL 官网倡议，能够应用 VARCHAR 代替 CHAR。 ...

@[toc] 装置mysql和mysql workbench装置mysql进入官网 https://dev.mysql.com/downloa... 找到本人须要的mysql installer x64 或 x32进入下载页，开始下载，下载后 失去 mysql-installer-community-8.0.23.0.msi 抉择 No thanks, just start my download.开始装置 mysql一路傻瓜next装置server 一路next设置账号密码 始终next，直到装置胜利装置胜利后在本人的开始菜单外面会有mysql的程序 关上控制台，输出明码 ## 装置workbench 下载地址 https://dev.mysql.com/downloa... 抉择 No thanks, just start my download.开始装置 workbench始终next即可装置实现后 关上workbench 连贯数据库 开始欢快的游玩吧

datagrip应用mysqldump导出sql呈现（1109）谬误1. 软件环境本地mysql版本为8.0服务器mysql版本为5.72. 遇到的问题应用datagrip IDE导出服务器中的表构造时(如图)，datagrip提醒谬误： mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'ais' AND TABLE_NAME = 'address_area';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)3. 问题解析因为本地环境是mysql8.0, 在 MySQL 8.x 之前，information_schema 数据库中没有 COLUMN_STATISTICS 数据表，应用8.0的mysqlclint拜访5.7版本，就会报错 4. 解决方案在上图的导出界面最下方增加 --column-statistics=0 即可疏忽这个表，如图

一、前言明天一个共事问我，如何应用 Mysql 实现相似于 ElasticSearch 的全文检索性能，并且对检索关键词跑分？我过后脑子里立马产生了疑难？为啥不间接用es呢？简略好用还贼快。然而听他说，数据量不多，客户给的工夫十分无限，基本没工夫去搭建es，所以还是看一下 Mysql 的全文检索性能吧！MySQL 从 5.7.6 版本开始，MySQL就内置了ngram全文解析器，用来反对中文、日文、韩文分词。在 MySQL 5.7.6 版本之前，全文索引只反对英文全文索引，不反对中文全文索引，须要利用分词器把中文段落预处理拆分成单词，而后存入数据库。本篇文章测试的时候，采纳的 Mysql 5.7.6 ，InnoDB数据库引擎。原文解析 二、全文解析器ngramngram就是一段文字外面间断的n个字的序列。ngram全文解析器可能对文本进行分词，每个单词是间断的n个字的序列。例如，用ngram全文解析器对“你好世界”进行分词: n=1: '你', '好', '世', '界' n=2: '你好', '好世', '世界' n=3: '你好世', '好世界' n=4: '你好世界'MySQL 中应用全局变量 ngram_token_size 来配置 ngram 中 n 的大小，它的取值范畴是1到10，默认值是 2。通常ngram_token_size设置为要查问的单词的最小字数。如果须要搜寻单字，就要把ngram_token_size设置为 1。在默认值是 2 的状况下，搜寻单字是得不到任何后果的。因为中文单词起码是两个汉字，举荐应用默认值 2。 咱们看一下Mysql默认的ngram_token_size大小： show variables like 'ngram_token_size' ngram_token_size 变量的两种设置形式： 1、启动mysqld命令时指定mysqld --ngram_token_size=22、批改mysql配置文件[mysqld] ngram_token_size=2三、全文索引以某文书数据为例，新建数据表 t_wenshu ，并且针对文书内容字段创立全文索引，导入10w条测试数据。 1、建表时创立全文索引 CREATE TABLE `t_wenshu` ( `province` varchar(255) DEFAULT NULL, `caseclass` varchar(255) DEFAULT NULL, `casenumber` varchar(255) DEFAULT NULL, `caseid` varchar(255) DEFAULT NULL, `types` varchar(255) DEFAULT NULL, `title` varchar(255) DEFAULT NULL, `content` longtext, `updatetime` varchar(255) DEFAULT NULL, FULLTEXT KEY `content` (`content`) WITH PARSER `ngram`) ENGINE=InnoDB DEFAULT CHARSET=utf8;2、通过 alter table 形式 ...

>一位喜好技术的橘右京的哥哥橘左京 索引的作用索引用于疾速查找表中数据的值，若不应用索引Mysql就会进行逐行查找，数据量大的状况下效率极低；若应用索引，可疾速达到地位进行查找，不会去查找无用数据，效率高。索引就像书中的目录，可间接通过目录去查找内容所在页数，而不须要一页页的查找。 劣势及劣势：劣势： 1).数据量大的状况下大大放慢查问速度，升高数据据IO老本。2).通过索引对数据进行排序，升高数据排序的老本，升高CPU耗费。劣势 1).在新增、批改、删除时，索引也须要创立或保护，所消耗的工夫也会减少。2).索引实际上也是一张表，会寄存到一个索引文件中，保留了主键和索引字段，并指向实体类的记录，所以索引也占用肯定的空间，数据表中的数据会有最大上线设置，如果有大量的索引，可能数据表会更快达到上限值。应用准则正当应用索引，对于罕用于查问的字段进行设置索引，对于常常更新的表防止应用太多的索引。若数据量较小也不用应用索引，可能不会起到作用。 索引次要分类1).单值索引：一个索引只能蕴含一个列，一个表能够有多个单值索引。2).惟一索引：索引列的值必须惟一，但容许有空值。3).复合索引：即一个索引蕴含多个列索引语法创立索引：create [UNIQUE|FULLTEXT|SPATIAL] INDEX xd_dog_name [USING index_type] on dog 查看索引:create index 索引名称 on 表名(字段名称)删除索引:show index from 表名批改表索引:drop index 索引名称 on 表名为表中列增加一个主键索引。alert table 表名 add primary key(字段名)为表中列增加一个惟一索引(字段值必须惟一，能够有N个null)。alert table 表名 add unique 索引名称(字段名)为表中列增加一个一般索引。alert table 表名 add index 索引名称(字段名称)为表中列增加一个全文索引。alert table 表名 add fulltext 索引名称(字段名称)索引设计准则1).对查问操作多且数据量大的表建设索引。2).索引字段的抉择最佳候选该当从where语句子条件提取。3).索引并不是越多越好，尤其增删改操作越多，保护索引的老本就越高。4).若有过多索引Mysql会呈现抉择艰难症，尽管最初会抉择一个无效的索引，但无疑减少了工夫耗费。5).应用惟一索引，区分度越高检索效率越高。6).应用短索引，索引创立后也是用硬盘存储，可晋升索引拜访的IO效率，也可晋升总体效率。7).利用最左索引，应用复合索引创立的索引，只有蕴含创立时的第一个字段就能够应用索引。如：id name age 搜寻id的时候可应用索引、搜寻ID Name的时候也可应用索引、搜寻ID Name Age的时候也能够应用索引新的一年新气象，new出对象不重样。

LINUX常用命令https://www.runoob.com/linux/... SQL罕用函数https://www.runoob.com/mysql/... 如何连贯数据库serverletspringboot多态一句话解释多态：多态就是一个事物多种状态，就是同一符号或者名字在不同状况下具备不同解释的景象。 多态是同一个行为具备多个不同表现形式或状态的能力。 多态就是同一个接口，应用不同的实例而执行不同操作，如图所示： 如何实现多态1.用抽象类实现多态 抽象类和形象办法实现多态性父类提供一系列规定, 束缚子类的行为父类能够提供一些共性的行为2.用接口实现多态 生存中的接口最具代表性的就是插座，例如一个三接头的插头都能接在三孔插座中，因为这个是每个国家都有各自规定的接口规定，有可能到国外就不行，那是因为国外本人定义的接口类型。java中的接口相似于生存中的接口，就是一些办法特色的汇合，但没有办法的实现。接口与抽象类的区别  　  抽象类是一类事物的高度聚合，那么对于继承抽象类的子类来说，对于抽象类来说，属于“是”的关系；而接口是定义行为规范，因而对于实现

Mysql 随机数1. 随机数rand() 随机获取0-1的数字ROUND(X) 示意将值 X 四舍五入为整数，无小数位FLOOR(X) 示意向下取整，只返回值X的整数局部，小数局部舍弃。CEILING(X) 示意向上取整，只返回值X的整数局部，小数局部舍弃。简略代码/** 随机值得范畴 rand() 随机获取0-1的数字 // 获取(min-max)的数字 round(rand()*(max-min) + min) */ # 随机1-10的整数select round(rand()*(10-1) + 1);

摘要：MySQL JDBC抽取到底应该采纳什么样的形式，且听小编给你娓娓道来。小编最近在云上的一个迁徙我的项目中被MySQL抽取模式折磨的很惨。一开始爆内存被客户怼，再起初迁徙效率低下再被怼。MySQL JDBC抽取到底应该采纳什么样的形式，且听小编给你娓娓道来。 1.1 Java-JDBC通信原理JDBC与数据库之间的通信是通过socket完，大抵流程如下图所示。Mysql Server ->内核Socket Buffer -> 客户端Socket Buffer ->JDBC所在的JVM 1.2 JDBC读取数据的三种模式1.2.1 形式1：应用JDBC默认参数读取数据次要分为以下几步： 1）Mysql Server通过OuputStream 向 Socket Server 本地Kennel Buffer 写入数据，这里是一次内存拷贝。 2）当Socket Server 本地Kennel Buffer 有数据，就会通过TCP链路把数据传输到Socket Client 所在机器的Kennel Buffer。 3）JDBC 所在JVM利用InputSream读取本地Kennel Buffer 数据到JVM内存，没有数据时，则读取被阻塞。 接下来就是一直反复1，2，3的过程。问题是，Socket Client 端的JVM在默认模式下读取Kennel Buffer是没有思考本机内存大小的，有多少读多少。如果数据太大，就会造成FULL GC，紧接着内存溢出。 参考 JDBC API docs，默认模式 Java demo 代码如下 1.2.2 形式2：游标查问为了解决形式1爆内存的问题，JDBC提供了一个游标参数，在建设jdbc连贯时加上useCursorFetch=true。设置游标后，JDBC 每次会通知Server端每次抽取的数据量，防止爆内存。通信过程如下图所示。 形式2游标查问尽管解决了内存溢出的问题，形式2极大的依赖网络品质。当网络时延增大，假如每次通信减少10ms，10万次通信就会多出1000s。这里仅仅是每次发申请的RT，TCP每次发送报文，都要求反馈ACK保证数据可靠性。client每取100行（申请行数可配置），就会有屡次通信，进一步放大时延减少导致的效率问题。此外，游标查问下，Mysql无奈预知查问的完结时延，为了应答本身的DML操作会在本地建设一个长期空间寄存要抽取的数据。因而，游标查问时会有以下几个景象产生 a. IOPS飙升，Mysql将数据写入到长期空间，数据传输时从长期空间读取数据，这都会引发大量IO操作。 b. 磁盘空间飙升，长期空间生命周期存在于整个JDBC读取阶段，直到客户端发动Result.close()时才会被Mysql回收。 c. CPU和内存有肯定比例回升。 无关游标查问的原理可参考博客MySQL JDBC StreamResult通信原理浅析以及JDBC源码，本文不在赘述。 参考 JDBC API docs，游标模式 Java demo 代码如下 ...

删除MySQL关上控制面板，找到无关MySQL的所有组件，删除。找到你的MysQL装置门路，看还有没有和MySQL无关的文件夹，全删。如果装置在C盘，检查一下C:\Program Files (x86)和C:\Program Files 这两个文件夹。删除对于MySQL的注册表，win+r，输出regedit，弹出注册表。删除HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\Application\MySQL文件夹 如果能找到如下内容，删除 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Eventlog\Application\MySQL HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MySQL 关上文件资源管理器，C:\ProgramData\MySQL，这是一个暗藏的文件夹，删除此文件夹。如果说文件在应用，关上工作管理器，看有没有MySQL的过程，关掉。重启电脑。

一、工夫戳转日期select FROM_UNIXTIME(1606028010, '%Y-%m-%d %H:%i:%s');二、日期转工夫戳select unix_timestamp('2018-01-15 09:45:16');三、工夫戳格式化十位工夫戳转为固定格局(yyyy-MM-dd HH:mm:ss)日期 1.格局规定%M 月名字(January……December)%W 星期名字(Sunday……Saturday)%D 有英语前缀的月份的日期(1st, 2nd, 3rd, 等等。）%Y 年, 数字, 4 位%y 年, 数字, 2 位%a 缩写的星期名字(Sun……Sat)%d 月份中的天数, 数字(00……31)%e 月份中的天数, 数字(0……31)%m 月, 数字(01……12)%c 月, 数字(1……12)%b 缩写的月份名字(Jan……Dec)%j 一年中的天数(001……366)%H 小时(00……23)%k 小时(0……23)%h 小时(01……12)%I 小时(01……12)%l 小时(1……12)%i 分钟, 数字(00……59)%r 工夫,12 小时(hh:mm:ss [AP]M)%T 工夫,24 小时(hh:mm:ss)%S 秒(00……59)%s 秒(00……59)%p AM或PM%w 一个星期中的天数(0=Sunday ……6=Saturday ）%U 星期(0……52), 这里星期天是星期的第一天%u 星期(0……52), 这里星期一是星期的第一天%% 一个文字“%”。select FROM_UNIXTIME(1567267200, '%Y-%m-%d %H:%i:%s'); 四、日期格式化select DATE_FORMAT('2020-12-15 11:19:27','%Y-%m-%d'); 五、转换13位工夫戳为10位工夫戳mysql中的工夫戳是10位的，间接截取下标1-10位就能够了 select substr(1567267200000, 1, 10); 六、以后工夫1.获取以后工夫select now();2.获取以后十位工夫戳select unix_timestamp(now());3.获取三天前工夫SELECT now() - interval 72 hour;

在之前的文章「简略理解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简略提一嘴，Buffer Pool是MySQL内存构造中非常外围的一个组成，你能够先把它设想成一个黑盒子。 黑盒下的更新数据流程当咱们查问数据的时候，会先去Buffer Pool中查问。如果Buffer Pool中不存在，存储引擎会先将数据从磁盘加载到Buffer Pool中，而后将数据返回给客户端；同理，当咱们更新某个数据的时候，如果这个数据不存在于Buffer Pool，同样会先数据加载进来，而后批改批改内存的数据。被批改过的数据会在之后对立刷入磁盘。 这个过程看似没啥问题，实则不讲武德。假如咱们批改Buffer Pool中的数据胜利，然而还没来得及将数据刷入磁盘MySQL就挂了怎么办？依照上图的逻辑，此时更新之后的数据只存在于Buffer Pool中，如果此时MySQL宕机了，这部分数据将会永恒的失落； 再者，我更新到一半忽然产生谬误了，想要回滚到更新之前的版本，该怎么办？那不完犊子吗，连数据长久化的保障、事务回滚都做不到还谈什么解体复原？ Redo Log & Undo Log而通过MySQL可能实现解体复原的事实来看，MySQL必然实现了某些骚操作。没错，这就是接下来咱们要介绍的另外的两个要害性能，Redo Log和Undo Log。 这两种日志是属于InnoDB存储引擎的日志，和MySQL Server的Binlog不是一个维度的日志。 Redo Log 记录了此次事务 「实现后」 的数据状态，记录的是更新之 「后」 的值Undo Log 记录了此次事务 「开始前」 的数据状态，记录的是更新之 「前」 的值所以这两种日志有显著的区别，我用一种更加艰深的例子来解释一下这两种日志。 Redo Log就像你在命令行敲了很长的命令，敲回车执行，后果报错了。此时咱们只须要再敲个↑就会拿到上一条命令，再执行一遍即可。 Undo Log就像你刚刚在Git中Commit了一下，而后再做一个较为简单的改变，然而改着改着你的心态崩了，不想要刚刚的改变了，于是间接git reset --hard $lastCommitId回到了上一个版本。 实现日志后的更新流程有了Redo Log和Undo Log，咱们再将下面的那张图给欠缺一下。 首先，更新数据还是会判断数据是否存在于Buffer Pool中，不存在则加载。下面咱们提到了回滚的问题，在更新Buffer Pool中的数据之前，咱们须要先将该数据事务开始之前的状态写入Undo Log中。假如更新到一半出错了，咱们就能够通过Undo Log来回滚到事务开始前。 而后执行器会更新Buffer Pool中的数据，胜利更新后会将数据最新状态写入Redo Log Buffer中。因为一个事务中可能波及到屡次读写操作，写入Buffer中分组写入，比起一条条的写入磁盘文件，效率会高很多。 那为什么Undo Log不也搞一个Undo Log Buffer，也给Undo Log提提速，雨露均沾？那咱们假如有这个一个Buffer存在于InnoDB，将事务开始前的数据状态写入了Undo Log Buffer中，而后开始更新数据。 忽然啪一下，很快啊，MySQL因为意外过程退出了，此时会产生一件很难堪的事件，如果更新的数据一部分曾经刷回磁盘了，然而此时事务没有胜利须要回滚，你发现Undo Log随着过程退出一起没了，此时就没有方法通过Undo Log去做回滚。 那如果刚刚更新完内存，MySQL就挂了呢？此时Redo Log Buffer甚至都可能没有写入，即便写入了也没有刷到磁盘，Redo Log也丢了。 ...

我是架构精进之路，点击上方“关注”，保持每天为你分享技术干货，私信我回复“01”，送你一份程序员成长进阶大礼包。发现的一些问题问题1 在过来的半年工夫里，研发团队外部尝试抓了一波儿慢查问SQL跟进处理率。发现有些同学对于慢查询处理的思路就是看看有没有用到索引，没有用到就试图加一个，切实不行就甩锅给这种状况是历史设计问题或者自行断定为用户非凡操作下触发的小概率事件，随即便申请豁免掉... 这样其实问题没有基本上解决。 问题2 还有就是网络上常常能够看到一些相似这样的文章： “慢SQL性能优化大全”“慢SQL性能优化看这篇就够了”......其实内容大同小异，要么倡议加索引，要么倡议重写SQL.... 怎么说呢？知识点是对的，但不全面，这个很容易误导新同学，哈哈哈。 本文初衷在业务我的项目倒退过程中，咱们经常会面对要解决 MySQL 慢查问问题，那咱们应该如何剖析解决问题呢？ 局部同学在解决MySQL慢查问时候次要思路是加索引来解决，的确加索引是一个很好的解决问题的伎俩，但不是全副。既然慢查问作为问题，那就须要明确问题产生起因，和解决问题路径分析， 授人以鱼不如授人以渔，让咱们一起来解锁 ???? 下MySQL解决慢查问的正确姿态。本文打算次要让大家搞明确查问SQL为什么会变慢，废话不多说，间接开干\~ 写在后面在业务我的项目倒退过程中，咱们经常会面对要解决 MySQL 慢查问问题，那咱们应该如何剖析解决问题呢？ 局部同学在解决MySQL慢查问时候次要思路是加索引来解决，的确加索引是一个很好的解决问题的伎俩，但不是全副。既然慢查问是问题，那就须要明确问题产生起因，和解决问题路径分析。咱们一起来get下MySQL慢查问的正确姿态。 本文次要内容包含： 1、查问SQL执行到底经验了什么？ 2、查问SQL为什么会慢？ 查问SQL执行到底经验了什么？=================== 首先须要明确：一个查问SQL的执行到底经验了什么？ 数据库执行SQL的大抵流程如下： 1）建设与MySQL服务器连贯（根底） 2）客户端发送查问SQL到数据库，数据库验证是否有执行的权限 3）MySQL服务器先查看查问缓存，如果命中了缓存，则立刻返回存储在缓存中的后果，否则持续流转； 4）MySQL服务器语法解析器，进行词法与语法分析，预处理 5）流转至查问优化器生成执行打算 6）依据生成的执行打算，调用存储引擎裸露的API来执行查问 7）将查问执行后果返回给客户端 8）敞开MySQL连贯 具体执行过程可能会因MySQL服务器具体配置和执行场景有一些差别。1）如未开启利用查问缓存，则间接疏忽查问缓存的查看； 2）执行过程中，如同时对于被扫描的行可能加锁，同时也可能会被其余sql阻塞 查问SQL为什么会慢？=============== 咱们能够把查问SQL执行看做是一个工作的话，那它是由一些列子工作组成的，每个子工作都存在肯定的工夫耗费。通常状况下，导致慢查问最基本的问题就是须要拜访的数据太多，导致查问不可避免的须要筛选大量的数据。 面对慢查问，咱们须要留神以下两点： 1）查问了过多不须要的数据 2）扫描了额定的记录 2.1 查问了过多不须要的数据MySQL并不是只返回须要的数据，实际上会返回全副后果集再进行计算。 尤其是多表关联查问 select * 的状况，咱们是不是真的须要全副的列呢？如果不是，那咱们间接指定对应字段就好了。 例如咱们要查问用户关联订单下的商品信息，如下所示： SELECT *FROM users  LEFT JOIN orders ON orders.user_id = users.user_id  LEFT JOIN goods ON goods.good_id = orders.good_idWHERE users.name = 'zhangsan'; 这将返回三个表的全副数据列，能够调整为仅取须要的列： SELECT goods.title, goods.descriptionFROM users  LEFT JOIN orders ON orders.user_id = users.user_id  LEFT JOIN goods ON goods.good_id = orders.good_idWHERE users.name = 'zhangsan'; ...

各类数据库的validationQuery语句DataBase validationQuery hsqldb select 1 from INFORMATION_SCHEMA.SYSTEM_USERSOracle select 1 from dualDB2 select 1 from sysibm.sysdummy1MySql select 1Microsoft SqlServer select1postgresql select version()ingres select 1derby values 1H2 select 1

DockerDocker 是一个开源的利用容器引擎，基于 Go 语言 并听从 Apache2.0 协定开源。Docker 能够让开发者打包他们的利用以及依赖包到一个轻量级、可移植的容器中，而后公布到任何风行的 Linux 机器上，也能够实现虚拟化。容器是齐全应用沙箱机制，相互之间不会有任何接口（相似 iPhone 的 app）,更重要的是容器性能开销极低。Docker 从 17.03 版本之后分为 CE（Community Edition: 社区版） 和 EE（Enterprise Edition: 企业版），咱们用社区版就能够了。 Mysql数据库（Database）是依照数据结构来组织、存储和治理数据的仓库。每个数据库都有一个或多个不同的 API 用于创立，拜访，治理，搜寻和复制所保留的数据。咱们也能够将数据存储在文件中，然而在文件中读写数据速度绝对较慢。所以，当初咱们应用关系型数据库管理系统（RDBMS）来存储和治理大数据量。所谓的关系型数据库，是建设在关系模型根底上的数据库，借助于汇合代数等数学概念和办法来解决数据库中的数据。 先去dockerhub里找到mysql对应的版本进行拉取https://registry.hub.docker.c... 应用docker进行命令拉取 docker images查看镜像 docker run -d -e MYSQL_ROOT_PASSWORD=123456 -p 3456:3306 mysql:5.6 **MYSQL_ROOT_PASSWORD 数据库明码3456:3306 3306端口占用应用3456映射** 进入mysql容器docker exec -ti xxx(容器id) /bin/bash 应用Navicat进行测试连贯docker搭建的mysql 实现！！！！

图片: https://uploader.shimo.im/f/y... 往期文章举荐mysql那些事儿|深入浅出mysql索引(上)mysql那些事儿|深入浅出mysql索引(下)为什么Mysql用B+树做索引而不必B-树或红黑树？mysql那些事儿|mysql事务隔离机制及其原理校招mysql那些事儿|日志模块binlog/redolog/undolog校招mysql那些事|MVCC原理机制mysql那些事儿|mysql锁总结目录锁定义锁分类读锁和写锁表锁和行锁InnoDB共享锁和排他锁InnoDB意向锁和排他锁InnoDB行锁InnoDB间隙锁 概念InnoDB应用间隙锁目标InnoDB行锁实现形式闲聊欢送退出我的公众号【迈莫coding】 一起pk大厂锁定义锁是计算机协调多个过程或线程并发拜访某一资源的机制。 在数据库中，除了传统的计算资源(如CPU, RAM, I/O等)的争用以外，数据也是一种供须要用户共享的资源。锁抵触也是影响数据库并发拜访性能的一个重要因素。 锁分类从性能上分为乐观锁(用版本比照来实现)和乐观锁从数据库操作的类型分为读锁和写锁(都属于乐观锁)从对数据操作的粒度分：分为表锁和行锁读锁和写锁读锁(共享锁)：针对同一份数据，多个读操作能够同时进行而不会相互影响，然而会阻塞写操作写锁(互斥锁)：以后写操作没有实现前，它会阻断其余写锁和读锁表锁和行锁表锁 每次操作时会锁住整张表。开销小，加锁快；不会产生死锁；锁定粒度大，产生锁抵触的概率最高；并发度最低；表锁更适宜于以查问为主，并发用户少，只有大量按索引条件更新数据的利用，如Web利用行锁 每次操作锁住一行数据。开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低；并发度最高；行级锁只在存储引擎层实现，而mysql服务器没有实现。行级锁更适宜于有大量按索引条件并发更新大量不同数据，同时又有并发查问的利用，如一些- 在线事务处理(OLTP)零碎InnoDB共享锁和排他锁InnoDB实现了两种类型的行锁： 共享锁(S): 容许一个事务去读一行，阻止其余事务取得雷同数据集的排他锁排他锁(X): 容许取得排他锁的事务更新数据，阻止其余事务获得雷同数据集的共享读锁和排他写锁为了容许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种外部应用的意向锁(Intention Locks)，这两种意向锁都是表锁： 动向共享锁(IS)：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先获得该表的IS锁动向排他锁(IX)：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先获得该表的IX锁InnoDB意向锁和排他锁意向锁是 InnoDB 引擎主动加的，不须要用户干涉对于 UPDATE INSERT DELETE 语句，InnoDB引擎会主动给波及数据集加排他锁(X)对于一般 SELECT 语句，InnoDB不会加任何锁事务能够通过以下语句显式地给后果集加共享锁或排它锁 共享锁（S）: SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 。 其余 session 依然能够查问记录，并也能够对该记录加 share mode 的共享锁。然而如果以后事务须要对该记录进行更新操作，则很有可能造成死锁。排它锁（X）： SELECT * FROM table_name WHERE ... FOR UPDATE 。其余 session 能够查问该记录，然而不能对该记录加共享锁或排他锁，而是期待取得锁InnoDB行锁innoDB行锁通过索引上的索引项加锁来实现的，这一点 MySQL 与 Oracle 不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB 这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB 才应用行级锁，否则，InnoDB 将应用表锁！不论是应用主键索引、惟一索引或一般索引，InnoDB 都会应用行锁来对数据加锁。只有执行打算真正应用了索引，能力应用行锁：即使在条件中应用了索引字段，但是否应用索引来检索数据是由 MySQL 通过判断不同执行打算的代价来决定的，如果 MySQL 认为全表扫描效率更高，比方对一些很小的表，它就不会应用索引，这种状况下 InnoDB 将应用表锁，而不是行锁。因为 MySQL 的行锁是针对索引加的锁，不是针对记录加的锁，所以尽管多个session拜访不同行的记录， 然而如果是应用雷同的索引键， 是会呈现锁抵触的（后应用这些索引的session须要期待先应用索引的session开释锁后，能力获取锁）。 利用设计的时候要留神这一点。InnoDB间隙锁概念当咱们用范畴条件而不是相等条件检索数据，并申请共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范畴内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。 ...

mysql如何查看行格局？ 查看行格局的命令SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLES where name; 反对配置file-format的目标是为了兼容晚期的老版本，在8.0之前的版本中，次要反对两种文件格式： Antelope： 对应的行格局为COMPACT及REDUNDANT行格局Barracuda：新的文件格式，对应行格局为COMPRESSED及DYNAMIC参考链接：MySQL · 8.0新变动 · 那些隐没的parameter, feature, etc... MySQL 查看数据表构造以及详情的办法

设置 MySql 数据同步摘要　mysql从3.23.15版本当前提供数据库复制性能。利用该性能能够实现两个数据库同步，主从模式，相互备份模式的性能。　数据库同步复制性能的设置都在mysql的设置文件中体现。mysql的配置文件（个别是my.cnf）　在unix环境下在/etc/mysql/my.cnf 或者在mysql用户的home目录上面的my.cnf。　window环境中，如果c:根目录下有my.cnf文件则取该配置文件。当运行mysql的winmysqladmin.exe工具时候，该工具会把c:根目录下的my.cnf 命名为mycnf.bak。并在winnt目录下创立my.ini。mysql服务器启动时候会读该配置文件。所以能够把my.cnf中的内容拷贝到my.ini文件中，用my.ini文件作为mysql服务器的配置文件。设置办法：设置范例环境：　操作系统：window2000 professional　mysql：4.0.4-beta-max-nt-log　A ip:10.10.10.22　B ip:10.10.10.53A:设置　1.减少一个用户最为同步的用户帐号：GRANT FILE ON . TO backup@'10.10.10.53' IDENTIFIED BY ‘1234'　2.减少一个数据库作为同步数据库：create database backupB:设置　1.减少一个用户最为同步的用户帐号：GRANT FILE ON . TO backup@'10.10.10.22' IDENTIFIED BY ‘1234'　2.减少一个远程桌面 s: in �����<数据库作为同步数据库：create database backup　主从模式：A->B　A为master　批改A mysql的my.ini文件。在mysqld配置项中退出上面配置：server-id=1log-bin 设置须要记录log 能够设置log-bin=c:mysqlbakmysqllog 设置日志文件的目录，其中mysqllog是日志文件的名称，mysql将建设不同扩展名，文件名为mysqllog的几个日志文件。binlog-do-db=backup #指定须要日志的数据库　重起数据库服务。　用show master status 命令看日志状况。　B为slave　批改B mysql的my.ini文件。在mysqld配置项中退出上面配置：server-id=2master-host=10.10.10.22master-user=backup #同步用户帐号master-password=1234master-port=3306master-connect-retry=60 预设重试距离60秒replicate-do-db=backup 通知slave只做backup数据库的更新　重起数据库　用show slave status看同步配置状况。　留神：因为设置了slave的配置信息，mysql在数据库目录下生成master.info　所以如有要批改相干slave的配置要先删除该文件。否则批改的配置不能失效。　双机互备模式。　如果在A退出slave设置，在B退出master设置，则能够做B->A的同步。　在A的配置文件中 mysqld 配置项退出以下设置：master-host=10.10.10.53master-user=backupmaster-password=1234replicate-do-db=backupmaster-connect-retry=10　在B的配置文件中 mysqld 配置项退出以下设置：log-bin=c:mysqllogmysqllogbinlog-do-db=backup　留神：当有谬误产生时*.err日志文件。同步的线程退出，当纠正错误后要让同步机制进行工作，运行slave start　重起AB机器，则能够实现双向的热备。　测试：　向B批量插入大数据量表AA（1872000）条　A数据库每秒钟能够更新2500条数据。 ...

创立索引： create index idx_test_c1234 on test(c1,c2,c3,c4);测试索引： -- 全值匹配能够应用索引EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c3`='a3' AND `c4`='a4';-- 查问优化器优化后能够应用索引EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c4`='a4' AND `c3`='a3';-- 查问优化器优化后能够应用索引EXPLAIN SELECT * FROM test WHERE `c4`='a4' AND `c3`='a3' AND `c2`='a2' AND `c1`='a1';-- 只能用到前三个索引，第四个生效EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c3`>'a3' AND `c4`='a4';-- 能够用到四个索引，第四个用于排序，查问优化器会优化为：AND `c3`='a3' AND `c4`>'a4';EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c4`>'a4' AND `c3`='a3';-- 查找用到了两个索引，排序用到了一个索引，无 filesortEXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c4`='a4' ORDER BY c3;-- 查找用到了两个索引，排序用到了一个索引，无 filesortEXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' ORDER BY c3;-- 查找用到了两个索引，排序没有用到索引，而是应用了文件排序EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' ORDER BY c4;-- 查找用到了一个索引，排序用到了两个索引，无 filesortEXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c5`='a5' ORDER BY c2, c3;-- 查找用到了一个索引，排序无奈应用索引EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c5`='a5' ORDER BY c3, c2;-- 查找用到了两个索引，排序用到了两个索引，无 filesortEXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' ORDER BY c2, c3;EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c5`='a5' ORDER BY c2, c3;-- 查找用到了两个索引，排序应用了一个索引（查问条件中c2是常量，只有惟一值，不须要再进行排序），无 filesortEXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2`='a2' AND `c5`='a5' ORDER BY c3, c2;-- 查找用到了一个索引，分组能够应用索引EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c4`='a4' GROUP BY c2, c3;-- 查找用到了一个索引，分组没有应用索引（应用了长期表和文件排序）-- 分组的前提是排序，分组的索引准则基本上与排序统一EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c4`='a4' GROUP BY c3, c2;-- 查找用到了三个索引，含糊查问后的字段能够持续应用索引（与大于小于不同）EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2` like 'kk%' AND c3='a3';-- 查找用到了一个索引，含糊查问不能应用索引EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2` like '%kk' AND c3='a3';EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2` like '%kk%' AND c3='a3';-- 查找用到了三个索引，含糊查问后的字段能够持续应用索引（与大于小于不同）EXPLAIN SELECT * FROM test WHERE `c1`='a1' AND `c2` like 'k%kk%' AND c3='a3';索引的优化倡议： ...

通配符结尾的含糊查问like 查问以通配符结尾时无奈应用索引而应用全表扫描。 EXPLAIN SELECT * FROM staffs WHERE `name` like '%July%';EXPLAIN SELECT * FROM staffs WHERE `name` like '%July'; 通配符结尾的含糊查问like 查问以通配符结尾能够应用索引，类型为范畴（range）。 EXPLAIN SELECT * FROM staffs WHERE `name` like 'July%'; 应用笼罩索引的含糊查问应用笼罩索引能够解决 like 查问以通配符结尾无奈应用索引问题。 ALTER TABLE `tbl_user` ADD INDEX idx_user_nameAge(`name`, `age`);EXPLAIN SELECT id FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT `name` FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT age FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT id,`name`,age FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT id,`name` FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT id,age FROM tbl_user WHERE `name` like '%July%';EXPLAIN SELECT `name`,age FROM tbl_user WHERE `name` like '%July%'; ...

1.批改配置信息： vim /etc/mysql/mysql.conf.d/mysqld.conf批改如下信息：[mysqld]skip-grant-tables保留2.登录mysql客户端： mysql -uroot -p 回车3.批改明码： update mysql.user set authentication_string=password("新密码") where user="root";4.减少用户和权限： GRANT ALL PRIVILEGES ON *.* TO pk_mysql@"%" IDENTIFIED BY '123456' WITH GRANT OPTION;flush privileges;5.编辑配置文件，把skip-grant-tables正文掉

1. 进行服务win + r 输出services.mvc 找到MYSQL进行之前的数据库服务 2. 解压数据库压缩文件增加my.ini文件，并增加配置 [mysqld]port = 3307basedir=E:\mysql-8.0.23-winx64 (1)\mysql-8.0.23-winx64datadir=E:\mysql-8.0.23-winx64 (1)\mysql-8.0.23-winx64\datamax_connections=200character-set-server=utf8default-storage-engine=INNODBsql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES[mysql]default-character-set=utf83.启动数据库服务以管理员的身份运行命令窗口 进入新mysql的bin目录下，装置mysql服务 mysqld install mysql2 --default-file="C:\mysql-5.7.22-winx64\my.ini"如果提醒失落 vcruntime140_1.dll 文件，你须要下载Microsoft Visual C ++ 2015，装置后，没用，依旧会报错，还须要下载Microsoft Visual C ++ Redistributable，而后在重新安装mysql服务，问题得以解决。 1. 胜利装置后会提醒：2. Service successfully installed.去服务里查看，会发现多了一个mysql2的服务 4.初始化数据库mysql服务装置胜利后，就须要初始化数据库了，否则是无奈启动服务的。在数据库的bin目录下输出以下命令 mysqld --initialize初始化胜利后，命令行没有任何提醒。但在mysql文件夹中已主动生成了data目录 5.批改注册服务win + r 输出 regedit 关上注册表找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mysql2，批改ImagePath参数 批改ImagePath参数： 6.批改明码应用net start mysql2 命令启动mysql2服务 mysql2服务启动后，去data/xxx.err文件中找到长期明码，进行登录 应用长期明码进行登录,并批改明码 mysqladmin -P3307 -u root -p password7.客户端连贯应用客户端连贯时会呈现Client does not support authentication protocol requested by server 谬误 ...

前言： 要理解一个数据库，咱们必须理解其反对的数据类型。MySQL 反对大量的字段类型，其中罕用的也有很多。后面文章咱们也讲过 int 及 varchar 类型的用法，但始终没有全面讲过字段类型，本篇文章咱们将把字段类型一网打尽，讲一讲常用字段类型的用法。 罕用的字段类型大抵能够分为数值类型、字符串类型、日期工夫类型三大类，上面咱们依照分类顺次来介绍下。 1.数值类型数值类型大类又能够分为整型、浮点型、定点型三小类。 整型次要用于存储整数值，次要有以下几个字段类型： 整型常常被用到，比方 tinyint、int、bigint 。默认是有符号的，若只需存储无符号值，可减少 unsigned 属性。 int(M)中的 M 代表最大显示宽度，并不是说 int(1) 就不能存储数值10了，不论设定了显示宽度是多少个字符，int 都是占用4个字节，即int(5)和int(10)可存储的范畴一样。 存储字节越小，占用空间越小。所以本着最小化存储的准则，咱们要尽量抉择适合的整型，例如：存储一些状态值或人的年龄能够用 tinyint ；主键列，无正数，倡议应用 int unsigned 或者 bigint unsigned，预估字段数字取值会超过 42 亿，应用 bigint 类型。 浮点型次要有 float，double 两个，浮点型在数据库中寄存的是近似值，例如float(6,3)，如果插入一个数123.45678，理论数据库里存的是123.457，但总个数还以理论为准，即6位，整数局部最大是3位。 float 和 double 平时用的不太多。 定点型字段类型有 DECIMAL 一个，次要用于存储有精度要求的小数。 DECIMAL 从 MySQL 5.1 引入，列的申明语法是 DECIMAL(M,D) 。 NUMERIC 与 DECIMAL 同义，如果字段类型定义为 NUMERIC ，则将主动转成 DECIMAL 。 对于申明语法 DECIMAL(M,D) ，自变量的值范畴如下： M是最大位数（精度），范畴是1到65。可不指定，默认值是10。D是小数点左边的位数（小数位）。范畴是0到30，并且不能大于M，可不指定，默认值是0。例如字段 salary DECIMAL(5,2)，可能存储具备五位数字和两位小数的任何值，因而能够存储在salary列中的值的范畴是从-999.99到999.99。 2.字符串类型字符串类型也常常用到，罕用的几个类型如下表： 其中 char 和 varchar 是最罕用到的。char 类型是定长的，MySQL 总是依据定义的字符串长度调配足够的空间。当保留 char 值时，在它们的左边填充空格以达到指定的长度，当检索到 char 值时，尾部的空格被删除掉。varchar 类型用于存储可变长字符串，存储时，如果字符没有达到定义的位数，也不会在前面补空格。 ...

应用不等于（!=或<>）时无奈应用索引而应用全表扫描。 EXPLAIN SELECT * FROM staffs WHERE `name` != 'July';EXPLAIN SELECT * FROM staffs WHERE `name` <> 'July';应用 is null, is not null 时无奈应用索引而应用全表扫描。 EXPLAIN SELECT * FROM staffs WHERE `name` is null;EXPLAIN SELECT * FROM staffs WHERE `name` is not null;应用 OR 做查问时无奈应用索引而应用全表扫描。 EXPLAIN SELECT * FROM staffs WHERE `name` = 'July' OR `name` = 'Sumi';

在索引列上做任何操作，都会导致索引生效而应用全表扫描。 创立索引： ALTER TABLE `staffs` ADD INDEX idx_staffs_nameAgePos(`name`, `age`, `pos`);在索引列上做计算或函数导致索引生效： EXPLAIN SELECT * FROM staffs WHERE LEFT(`name`, 4)='July'; 在索引列上做类型转换（显式、隐式）导致索引生效： EXPLAIN SELECT * FROM staffs WHERE `name`=2000; -- varchar(64)

如果查问中的某列呈现范畴查问，则该列左边的列不能应用索引。 应用示例创立索引： ALTER TABLE `staffs` ADD INDEX idx_staffs_nameAgePos(`name`, `age`, `pos`);应用范畴查问： EXPLAIN SELECT * FROM staffs WHERE `name`='July' AND age>25 AND pos='dev'; 后果： name 的索引列能够用于准确查找。 age 的索引列能够用于范畴查找。 pos 的索引列生效。

什么是最左前缀准则如果一个索引蕴含了多个列，查问必须从索引的最左前列开始，并且不能跳过索引中的列。 应用示例创立索引： ALTER TABLE `staffs` ADD INDEX idx_staffs_nameAgePos(`name`, `age`, `pos`);应用单列的全值匹配查问： EXPLAIN SELECT * FROM staffs WHERE `name`='July'; 应用两列的全值匹配查问： EXPLAIN SELECT * FROM staffs WHERE `name`='July' AND age=25; 应用三列的全值匹配查问： EXPLAIN SELECT * FROM staffs WHERE `name`='July' AND age=25 AND pos='dev'; 不是从最左前列开始，不能应用索引： EXPLAIN SELECT * FROM staffs WHERE age=25 AND pos='dev'; 不是从最左前列开始，不能应用索引： EXPLAIN SELECT * FROM staffs WHERE pos='dev'; 从最左前列开始，但跳过了索引中的列，能够局部应用索引： EXPLAIN SELECT * FROM staffs WHERE `name`='July' AND pos='dev';

什么是二进制日志(binlog)binlog是记录所有数据库表构造变更（例如CREATE、ALTER TABLE…）以及表数据批改（INSERT、UPDATE、DELETE…）的二进制日志。 binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据自身并没有批改，但你能够通过查问通用日志来查看MySQL执行过的所有语句。 二进制日志包含两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查问语句)语句事件。 什么是事务日志innodb事务日志包含redo log和undo log。 undo log指事务开始之前， 在操作任何数据之前,首先将需操作的数据备份到一个中央 redo log指事务中操作的任何数据,将最新的数据备份到一个中央 事务日志的目标：实例或者介质失败，事务日志文件就能派上用场。 1.redo log不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo 中。具体 的落盘策略能够进行配置 。避免在产生故障的工夫点，尚有脏页未写入磁盘，在重启mysql服务的时候，依据redo log进行重做，从而达到事务的未入磁盘数据进行长久化这一个性。RedoLog是为了实现事务的持久性而呈现的产物2.undo log用来回滚行记录到某个版本。事务未提交之前，Undo保留了未提交之前的版本数据，Undo中的数据可作为数据旧版本快照供其余并发事务进行快照读。是为了实现事务的原子性而呈现的产物,在Mysql innodb存储引擎中用来实现多版本并发管制 Redolog常识补充指定Redo log 记录在{datadir}/ib_logfile1&ib_logfile2 可通过innodb_log_group_home_dir 配置指定 目录存储 一旦事务胜利提交且数据长久化落盘之后，此时Redo log中的对应事务数据记录就失去了意义，所 以Redo log的写入是日志文件循环写入的 指定Redo log日志文件组中的数量 innodb_log_files_in_group 默认为2 指定Redo log每一个日志文件最大存储量innodb_log_file_size 默认48 指定Redo log在cache/buffer中的buffer池大小innodb_log_buffer_size 默认16Redo buffer 长久化Redo log的策略， Innodb_flush_log_at_trx_commit： 取值 0 每秒提交 Redo buffer --> Redo log OS cache -->flush cache to disk[可能失落一秒的事务数据] 取值 1 默认值，每次事务提交执行Redo buffer --> Redo log OS cache -->flush cache to dis[最平安，性能最差的形式] ...

什么是笼罩索引创立一个索引，该索引蕴含查问中用到的所有字段，称为“笼罩索引”。 应用笼罩索引，MySQL 只须要通过索引就能够查找和返回查问所须要的数据，而不用在应用索引解决数据之后再进行回表操作。 笼罩索引能够一次性实现查问工作，无效缩小IO，进步查问效率。 应用示例查问语句： SELECT col2, col3 FROM test_table WHERE col1 = xxx ORDER BY col2;创立一个单列索引： ALTER TABLE `test_table` ADD INDEX `idx_col1`(`col1`) USING BTREE;剖析查问： EXPLAIN SELECT SQL_NO_CACHE col2, col3 FROM test_table WHERE col1 = xxx ORDER BY col2;后果：对 col1 建设索引后，type 为 ref，应用到了 idx_col1 索引。 批改索引，依据查问语句，建设一个联结索引： ALTER TABLE `test_table` DROP INDEX `idx_col1`;ALTER TABLE `test_table` ADD INDEX `idx_col1_col2_col3`(`col1`，`col2`，`col3`) USING BTREE;剖析查问： EXPLAIN SELECT SQL_NO_CACHE col2, col3 FROM test_table WHERE col1 = xxx ORDER BY col2;后果：建设联结索引后，type 为 ref，应用了 idx_col1_col2_col3 索引，Extra 为 Using index，阐明应用了笼罩索引。 ...

以前备份binlog时，都是先在本地进行备份压缩，而后发送到近程服务器中。然而这其中还是有肯定危险的，因为日志的备份都是周期性的，如果在某个周期中，服务器宕机了，硬盘损坏了，就可能导致这段时间的binlog就失落了。 而且，以前用脚本对近程服务器进行备份的形式，有个毛病：无奈对MySQL服务器以后正在写的二进制日志文件进行备份。所以，只能等到MySQL服务器全副写完能力进行备份。而写完一个binlog的工夫并不固定，这就导致备份周期的不确定。 从MySQL5.6开始，mysqlbinlog反对将近程服务器上的binlog实时复制到本地服务器上。 mysqlbinlog的实时二进制复制性能并非简略的将近程服务器的日志复制过去，它是通过MySQL 5.6颁布的Replication API实时获取二进制事件。实质上，就相当于MySQL的从服务器。与一般服务器相似，主服务器产生事件后，个别都会在0.5~1秒内进行备份。 备份命令 复制代码 代码如下:mysqlbinlog --read-from-remote-server --raw --host=192.168.244.145 --port=3306 --user=repl --password=repl --stop-never mysql-bin.000001 解释如下： --read-from-remote-server：用于备份近程服务器的binlog。如果不指定该选项，则会查找本地的binlog。 --raw：binlog日志会以二进制格局存储在磁盘中，如果不指定该选项，则会以文本模式保留。 --user：复制的MySQL用户，只须要授予REPLICATION SLAVE权限。 --stop-never：mysqlbinlog能够只从近程服务器获取指定的几个binlog，也可将一直生成的binlog保留到本地。指定此选项，代表只有近程服务器不敞开或者连贯未断开，mysqlbinlog就会一直的复制近程服务器上的binlog。 mysql-bin.000001：代表从哪个binlog开始复制。 除了以上选项外，还有以下几个选项须要留神： --stop-never-slave-server-id：在备份近程服务器的binlog时，mysqlbinlog实质上就相当于一个从服务器，该选项就是用来指定从服务器的server-id的。默认为-1。 --to-last-log：代表mysqlbinlog不仅可能获取指定的binlog，还能获取其后生成的binlog，获取完了，才终止。如果指定了--stop-never选项则会隐式关上--to-last-log选项。 --result-file：用于设置近程服务器的binlog，保留到本地的前缀。譬如对于mysql-bin.000001，如果指定--result-file=/test/backup-，则保留到本地后的文件名为/test/backup-mysql-bin.000001。留神：如果将--result-file设置为目录，则肯定要带上目录分隔符“/”。譬如--result-file=/test/，而不是--result-file=/test，不然保留到本地的文件名为/testmysql-bin.000001。 有余： 这个形式有个问题，对于惯例的主从复制来说，如果主从间接的连贯断开了，则从会主动再次连贯，而对于mysqlbinlog，如果断开了，并不会主动连贯。 解决方案： 可通过脚本来补救上述有余。

作者：洪斌爱可生南区负责人兼技术服务总监，MySQL ACE，善于数据库架构布局、故障诊断、性能优化剖析，实践经验丰盛，帮忙各行业客户解决 MySQL 技术问题，为金融、运营商、互联网等行业客户提供 MySQL 整体解决方案。 本文起源：转载自公众号-玩转MySQL *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 你是否会常常遇到 MySQL hang 了而手足无措？面对繁冗的 callstack 信息如何能力疾速剖析出起因？ 本文将通过一个案例，介绍如何疾速剖析这类问题的办法。 当咱们遇到 MySQL hang 的场景时，大概率是程序外部产生了 mutex 抵触造成的。这时咱们须要在重启服务前，先收集 callstack 信息。 pstack `pidof mysqld` > mysql_callstack留神：mysqld 须要蕴含符号表 有了 callstack 信息，咱们便能够开始进行剖析了。 剖析步骤首先，在 callstack 日志筛选出每个线程调用 inline_mysql_mutex_lock 前的函数，以及对应的 mutex 代码地位，此处便是线程在期待的 mutex。 而后，从该函数向前遍历每个函数调用，寻找这些函数，看曾经胜利取得哪些 mutex。 这里我用脚本对日志进行格式化解决，将每个函数都映射到了 github 的代码地位，点击链接能够间接跳转，应用 Chrome 浏览器配合 sourcegraph 查看代码也很香。 最初，从日志中回溯每个上锁函数所对应的前端操作行为，并绘制一张对于线程持有和期待 mutex 的表格，便能直观的剖析出函数的抵触关系。 总结因为 show binlog logs 操作、purge binlog 以及从读取 performance_schema 读取会话变量几个操作并行产生产生 mutex 抵触，导致无奈新建连贯申请。 show binary logs，持有 LOCK_log，期待 LOCK_indexbinlog purge，持有 LOCK_index, 期待 LOCK_thd_data读取 performance_schema.session_variables，持有 LOCK_thd_data, LOCK_global_system_variables, 期待 LOCK_log新建连贯，期待 LOCK_global_system_variables最终确认是 binlog_transaction_dependency_* 变量的读取须要获取 LOCK_log 锁，此处容易造成死锁，MySQL 5.7.25 修复了此问题。 ...

truncate 语法truncate直译为截断，作用是清空表，且只能作用于表；语法为： truncate table tbl_name 或 truncate tbl_name truncate需领有表的drop权限，从逻辑上讲，truncate table相似于delete删除所有行的语句或drop table而后再create table语句的组合。为了实现高性能，它绕过了删除数据的DML办法，因而，它不能回滚。只管truncate table与delete类似，但它被分类为DDL语句而不是DML语句。 truncate & drop & deletetruncate & drop 是DDL语句，执行后无奈回滚；delete 是DML语句，可回滚。truncate 只能作用于表；delete & drop 可作用于表、视图等。truncate 会清空表中的所有行，但表构造及其束缚、索引等放弃不变；drop 会删除表的构造及其所依赖的束缚、索引等。truncate 会重置表的自增值；delete 不会。truncate 不会激活与表无关的删除触发器；delete 能够。truncate 后会使表和索引所占用的空间会复原到初始大小；delete 操作不会缩小表或索引所占用的空间，drop 语句将表所占用的空间全开释掉。truncate 应用场景面临大表时，如果想删除所有数据能够用truncate；如果和事务无关，或者想触发trigger，还是用delete；如果是整理表外部的碎片，能够用truncate而后再从新插入数据 truncate 注意事项truncate 无奈通过binlog回滚truncate 会清空所有数据且执行速度很快truncate 不能对有外键束缚援用的表应用truncate 须要drop权限，不倡议给账号drop权限truncate 前肯定要再三查看确认，最好提前备份下表数据

事务四个个性原子性：不可分割，在对数据库操作时，只有两个后果，胜利提交，失败回滚一致性：操作前后数据总和不变 隔离性：并发时，不能相互烦扰持久性：数据一但提交就不会失落隔离性差造成的后果读：脏读: 一个事物读到另一个事物未提交的数据不可反复读: 一个数据读到另一个事物曾经提交(update) 的数据, 导致一次事物中屡次查问的后果不统一 虚读, 幻读: 一个事物读到另一个事物曾经提交(insert)的数据,导致一个事务中屡次查问后果不统一写:失落更新: 并发批改导致的一个事物更新的数据被另一个事物更新之后冲掉解决方案Read uncommitted: 未提交读Read committed: 只能解决脏读 (oracle默认)Repeatable read: 解决脏读和不可反复读, 可能产生虚读 (mysql默认)Serializable: （串行化）所有读问题都能够解决, 然而效率太低表的关系1，一对一：主表和子表的主键一样（主表的主键也是子表的主键）2，一对多：在子表增加记录时增加一个外键FK3，多对一：同上4，多对多：须要一张表来存储两边的主键，它们两个合起来叫做复合主键索引作用：快速访问表中记录查找形式：全表遍历 索引表 索引表表遍历 排序 二分查找当创立主键时会主动创立索引表，索引要独自占用空间，它创立时会主动排序，不便疾速检索，利用相似二分法疾速查找数据 长处：性能高 毛病：额定占用空间，冗余。新增 批改 删除都会造成索引的重构，须要额定的工夫 数据量大时 不举荐应用 个别在where order by排序中的字段应用sql语言set @@autocommit =0;默认是1主动提交，0手动提交begin开始事务commit提交事务rollback回滚事务savepoint wang 零时存储点rollback to wang 回滚到存储点，复原数据单值子查问：子查问返回后果必须是单个字段，必须是单个值，能力用=两个字段名必须雷同select * from 表名 where 字段名 =（select 字段名 from 表名where 条件）多值子查问：SELECT * FROM 表名WHERE 字段 IN (SELECT 字段 FROM 表名 WHERE 表名 IN (100,200) )in子查问串，返回后果能够是多个值，然而必须是单列 INNER JOIN 内连贯 两表的交加LEFT JOIN 左连贯 右边表中的数据都呈现，左边没有数据以NULL填充RIGHT JOIN 右连贯 左边表中的数据都呈现，右边没有数据以NULL填充SELECT * FROM emp as e RIGHT JOIN empext as t ON e.empno = t.empno(as能够省略）设置索引alter table 表名 add unique （字段名）删除索引alter table 表名 drop index 字段名复合索引，多个索引列，进步查问速度，不具备唯一性判断ALTER TABLE 表名ADD INDEX idx_phone_cardno(phone,cardno)

sql/ 启动MySQL /net start mysql / 连贯与断开服务器 /mysql -h 地址 -P 端口 -u 用户名 -p 明码 / 跳过权限验证登录MySQL /mysqld --skip-grant-tables -- 批改root明码 明码加密函数password()update mysql.user set password=password('root'); SHOW PROCESSLIST -- 显示哪些线程正在运行 SHOW VARIABLES -- / 数据库操作 / ------------------ -- 查看以后数据库 select database();-- 显示以后工夫、用户名、数据库版本 select now(), user(), version();-- 创立库 create database[ if not exists] 数据库名 数据库选项 数据库选项： CHARACTER SET charset_name COLLATE collation_name-- 查看已有库 show databases[ like 'pattern']-- 查看以后库信息 show create database 数据库名-- 批改库的选项信息 alter database 库名 选项信息-- 删除库 drop database[ if exists] 数据库名 ...

前言首先思考一个问题:在高并发的场景中,对于数据库都有哪些优化的伎俩？罕用的有以下的实现办法:读写拆散、加缓存、主从架构集群、分库分表等，在互联网利用中,大部分都是读多写少的场景,设置两个库,主库和读库。 主库的职能是负责写,从库次要是负责读,能够建设读库集群,通过读写职能在数据源上的隔离达到缩小读写抵触、 释压数据库负载、爱护数据库的目标。在理论的应用中,但凡波及到写的局部间接切换到主库，读的局部间接切换到读库，这就是典型的读写拆散技术。本篇博文将聚焦读写拆散,探讨如何实现它。 目录一: 主从数据源的配置二: 数据源路由的配置三：数据源上下文环境四：切换注解和 Aop 配置五：用法以及测试六：总结 主从同步的局限性：这里分为主数据库和从数据库,主数据库和从数据库放弃数据库构造的统一,主库负责写,当写入数据的时候,会主动同步数据到从数据库；从数据库负责读,当读申请来的时候,间接从读库读取数据,主数据库会主动进行数据复制到从数据库中。不过本篇博客不介绍这部分配置的常识,因为它更偏运维工作一点。 这里波及到一个问题:主从复制的提早问题,当写入到主数据库的过程中,忽然来了一个读申请,而此时数据还没有齐全同步,就会呈现读申请的数据读不到或者读出的数据比原始值少的状况。具体的解决办法最简略的就是将读申请临时指向主库,然而同时也失去了主从拆散的局部意义。也就是说在严格意义上的数据一致性场景中,读写拆散并非是齐全适宜的,留神更新的时效性是读写拆散应用的毛病。 好了,这部分只是理解,接下来咱们看下具体如何通过 java 代码来实现读写拆散: 该我的项目须要引入如下依赖：springBoot、spring-aop、spring-jdbc、aspectjweaver 等 一: 主从数据源的配置咱们须要配置主从数据库,主从数据库的配置个别都是写在配置文件外面。通过@ConfigurationProperties 注解,能够将配置文件(个别命名为:application.Properties)里的属性映射到具体的类属性上,从而读取到写入的值注入到具体的代码配置中,依照习惯大于约定的准则,主库咱们都是注为 master,从库注为 slave。 本我的项目采纳了阿里的 druid 数据库连接池,应用 build 建造者模式创立 DataSource 对象,DataSource 就是代码层面形象进去的数据源,接着须要配置 sessionFactory、sqlTemplate、事务管理器等 /** * 主从配置 * * @author wyq */@Configuration@MapperScan(basePackages = "com.wyq.mysqlreadwriteseparate.mapper", sqlSessionTemplateRef = "sqlTemplate")public class DataSourceConfig { /** * 主库 */ @Bean @ConfigurationProperties(prefix = "spring.datasource.master") public DataSource master() { return DruidDataSourceBuilder.create().build(); } /** * 从库 */ @Bean @ConfigurationProperties(prefix = "spring.datasource.slave") public DataSource slaver() { return DruidDataSourceBuilder.create().build(); } /** * 实例化数据源路由 */ @Bean public DataSourceRouter dynamicDB(@Qualifier("master") DataSource masterDataSource, @Autowired(required = false) @Qualifier("slaver") DataSource slaveDataSource) { DataSourceRouter dynamicDataSource = new DataSourceRouter(); Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put(DataSourceEnum.MASTER.getDataSourceName(), masterDataSource); if (slaveDataSource != null) { targetDataSources.put(DataSourceEnum.SLAVE.getDataSourceName(), slaveDataSource); } dynamicDataSource.setTargetDataSources(targetDataSources); dynamicDataSource.setDefaultTargetDataSource(masterDataSource); return dynamicDataSource; } /** * 配置sessionFactory * @param dynamicDataSource * @return * @throws Exception */ @Bean public SqlSessionFactory sessionFactory(@Qualifier("dynamicDB") DataSource dynamicDataSource) throws Exception { SqlSessionFactoryBean bean = new SqlSessionFactoryBean(); bean.setMapperLocations( new PathMatchingResourcePatternResolver().getResources("classpath*:mapper/*Mapper.xml")); bean.setDataSource(dynamicDataSource); return bean.getObject(); } /** * 创立sqlTemplate * @param sqlSessionFactory * @return */ @Bean public SqlSessionTemplate sqlTemplate(@Qualifier("sessionFactory") SqlSessionFactory sqlSessionFactory) { return new SqlSessionTemplate(sqlSessionFactory); } /** * 事务配置 * * @param dynamicDataSource * @return */ @Bean(name = "dataSourceTx") public DataSourceTransactionManager dataSourceTransactionManager(@Qualifier("dynamicDB") DataSource dynamicDataSource) { DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager(); dataSourceTransactionManager.setDataSource(dynamicDataSource); return dataSourceTransactionManager; }}复制代码二: 数据源路由的配置路由在主从拆散是十分重要的,根本是读写切换的外围。Spring 提供了 AbstractRoutingDataSource 依据用户定义的规定抉择以后的数据源，作用就是在执行查问之前，设置应用的数据源,实现动静路由的数据源，在每次数据库查问操作前执行它的形象办法 determineCurrentLookupKey() 决定应用哪个数据源。 ...

设计models模型 from django.db import models # 积分信息class Credits(models.Model): user = models.ForeignKey(Visitors,on_delete=models.CASCADE,primary_key=True) credits_total = models.IntegerField('总积分',default=0) credits_buy = models.IntegerField('购买的积分',default=0) time_credits_buy = models.DateTimeField('购买的工夫',auto_now_add=True) credits_before_day = models.IntegerField('前一天签到的积分',default=0) time_sign_before_day = models.DateTimeField('前一天签到的工夫',default=None) class Meta(): # credits,为数据库中的表名 db_table = 'credits'python manage.py makemigrationspython manage.py migrateDjango主动生成models如果数据库表曾经存在，执行命令，能够主动生成Models模型，实现models与数据表的映射 python manage.py inspectdb > tools/models.py

根本函数lower（字段名）转小写upper（字段名）转大写length（字段名）数据的长度substr（字段名，截取结尾地位，完结地位）（含头含尾）截取concat（字段名，拼接内容）拼接数据replace（字段名，替换数据，替换内容）替换round四舍五入ceil向上取整floor向下取整max(字段名）求最大值min（字段名）求最小值sum（字段名）求和avg（字段名）求均匀select now() --年月日 时分秒select curdate() --年与日select curtime() --时分秒--year()年 month()月 day()日 select now(),year(now()),month(now()),day(now()) from emp;--hour()时 minute()分 second()秒select now(),hour(now()),minute(now()),second(now()) from emp;distinct去除反复的记录行SELECT DISTINCT 字段名 FROM 表名;过滤条件whereand 相当于& 关系or相当于|关系between and 两者之间is null 为空is not null 不为空含糊查问like %通配符、不限度个数-一个代表一个字符分页limit一个参数N 展现N条数据二个参数，S N从S开始展现N条数据排序by 排序字段 asc 默认从小到大desc 降序count（字段名）统计该字段的所有数据group by 字段名用于对查问的后果进行分组统计having 子句相似where限度返回后果，where用在主句中，having用在分组中

学过统计学的同学应该对置信区间都有理解，置信区间又叫预计区间，是从概率来讲某个随机变量可能取的值的范畴。 在后面的文章[聊聊置信度与置信区间]中讲过为什么会有置信区间以及置信区间应该如何求取。在那篇文章中讲了当数据遵从正态分布时，95%的置信区间就是均值加减1.96倍的标准差。 那很多时候数据是不合乎正态分布，或者是咱们不晓得样本总体是否合乎正态分布，然而咱们又须要求取置信区间时，就能够用到咱们的明天的配角--Bootstrap抽样的办法。 Bootstrap是对样本进行有放回的抽样，抽样若干次(个别为1000次)，每次抽样的后果作为一个样本点，抽样1000次，就会有1000个样本点，用这1000个点的散布作为样本总体的散布，而这1000个点是大概率是遵从正态分布的，只有遵从正态分布就能够依照正态分布的公式求取置信区间。 那为什么这1000个点是遵从正态分布的呢？根据的就是就是核心极限定理。 接下来咱们通过一个例子来看下，首先生成一个长尾散布的数据： from scipy.stats import fdfn, dfd = 45, 10r = f.rvs(dfn, dfd, size=10000)sns.distplot(r) 在理论业务中很多数据其实都是合乎长尾散布的。而后咱们对这个长尾散布的数据进行Bootstrap抽样，有放回的抽样1000次，每次抽10000个样本，最初失去1000个均值，这1000个均值的散布如下： import numpy as npsample_mean = []for n in range(1,1001):    s = np.random.choice(r,size = 10000).mean()    sample_mean.append(s)运行下面的代码失去如下后果： 能够看到这1000个均值是合乎正态分布的，只有合乎正态分布，那咱们就能够利用正态分布的性质对其进行估算。 以上就是对于Bootstrap的一个简略介绍，心愿对你有用。

明天咱们来聊聊什么是OC曲线，OC曲线是用来反映：一个批次的产品被接管的概率与该批次产品不合格率之间的关系。如下图这样的曲线： 横轴是该批次的整体不良率(不合格率)，纵轴是在该不合格率的状况有可能被消费者承受的概率。 是不是看下面这句话，不太懂什么意思，没关系，咱们持续往下看，说不准就懂了。 OC曲线次要是用来阐明抽样计划的个性的。通过曲线咱们就能晓得一个抽样计划的好坏。 假如当初你找了一个代工厂给你生产N台手机，代工厂生产完当前，你须要对这些手机的品质进行查看，那怎么查看呢？比较简单的办法就是把N台全副拆开来试用一遍，看看有没有问题，然而这种办法很显然不太正当。惯例的做法就是从全副N外面随机抽取n台手机进去，而后用这n台手机的状况来反映总体N台的状况。并且须要当时规定好，当n外面发现c台品质有问题的时候，就认为整个批次都有问题，须要让代工厂回去重做。 在下面这个过程中，存在两种危险，一种是代工厂的危险，也叫生产者危险；另一种是你的危险，也就是消费者危险。 生产者危险是指尽管你的产品的不合格率低于当时大家规定好的不合格率(咱们把这个当时定好的不合格率称为允收规范，简称AQL)，然而仍有可能被回绝的概率，因为咱们是通过抽样来计算你的产品的不合格率，而不是针对全副产品计算不合格率。 消费者危险是指尽管产品的不合格率大于当时规定好的不合格率(咱们把这个当时定好的不合格率称为拒收规范，简称LTPD)，然而仍有可能被接管的概率。 那为什么会呈现下面这两种危险呢？那是因为咱们的检测是抽样，而不是全量检测的起因。比方咱们晓得如果扔硬币足够屡次，难么侧面背面呈现的概率均是0.5，然而如果你只扔了10次，那么侧面和背面呈现的概率就不肯定是0.5了，这就是用抽样来对全副产品质量做判断时的容易存在的两类危险。 要解决下面提到的这两种危险的解法就是减少抽样的样本量，如果是对总体N进行查看，那么就不会呈现这种问题。然而对总体N查看须要付出很大的老本，所以须要在n和两个危险之间找到一个平衡点。即可接管危险范畴的最小样本数n。 接下来，咱们看下接管概率以及两类危险的具体取值应该如何计算。 假如总体N=1000，抽样n=100，有问题品质产品下限c = 2，不合格品率p为1.5%。因为有问题品质产品的下限是2，也就是从100个外面如果检测出有问题品质的产品数超过2，那么就回绝接管这批产品。对应的接管概率就是从100个产品中检测出0个、1个、2个有问题品质产品的概率之后。在求取接管概率时不同概率分布对应的求法是不一样的，有二项式散布、超几何散布、泊松散布等。 通过让不合格品率p取不同的值，能够求出不同p值对应的接管概率，把这些点连起来就是咱们结尾看到的OC曲线。 以上是如何计算接管概率，计算失去接管概率当前，咱们就能够计算两类危险值的大小。 生产者危险() = 1 - AQL对应的接管概率消费者危险() =  LTPD对应的接管概率个别的取值为0.05，的取值为0.1-0.2。

之前咱们讲过T测验、F测验，这一篇，咱们讲讲Q测验。Q测验又称舍弃商法，次要是用来对可疑值(异样值)进行取舍判断的。 比方当初做了若干次试验，而后失去了若干个观测值：10.14、10.12、10.25、10.16、10.20这几个值，通过观测值看到10.25与其余值之间相差比拟大，当初思考要不要将这个值当做异样值去掉呢？有没有什么判断根据，这个时候就能够用Q测验。 次要有如下几个步骤： step1：将所有观测数据依照从小到大的程序进行排列step2：求最大值与最小值之间的差值，称为极差step3：计算想删除值与其相邻值之间差值的绝对值step4：用step3算进去的值除step2算出的值，该值就是q统计量step5：依据观测值个数以及置信水平，查q值表q值表链接：https://www.docin.com/p-11047... step6：比拟q统计量与q值表中查出的后果，如果q统计量小于q值表查出来的后果，则不应该删除，否则就能够删除 Q测验的核心思想其实和t测验的核心思想是统一的，都是用来测验不同的观测值之间是否有显著差别，即是否来自于同一总体，如果差别不显著，则阐明是来自于同一总体，否则就不是。 Q测验除了被用在要不要剔除异样值以外，还次要用在多重比拟中，比方有多个组别，须要判断各个组别两两之间的差别水平时也会用到。咱们之前介绍的LSD就是多重比较法中最简略的一种。还有工夫序列的白噪声测验等等。

1.前言咱们在方差分析外面有讲过，方差分析有一个很重要的前提就是叫方差齐性。这一篇来讲讲如何来测验方差齐性。 先讲讲什么是方差齐性，方差齐性是指不同组间的总体方差是一样的。那为什么方差分析的前提是要组间的总体方差保持一致呢？先想想方差分析是做什么呢？方差分析是用来比拟多组之间均值是否存在显著差别。那如果方差不统一，也就意味着值的稳定水平是不一样的，如果此时均值之间存在显著差别，不可能阐明肯定是不同组间解决带来的，有可能是大方差带来大的稳定；如果方差一样，也就意味着值的稳定水平是一样的，在雷同稳定水平下，间接去比拟均值，如果均值之间存在显著差别，那么能够认为是不同组间解决带来的。 方差齐性测验是对两组样本的方差是否雷同进行测验。测验思维与均值之间差异性测验是一样的。罕用的办法有：方差比、Hartley测验、Levene测验、BF法、Bartlett测验。 2.方差比方差比顾名思义就是两组方差的比，用较大一组的方差除较小一组的方差，最初失去一个F值，而后依据F值的大小来判断两组之间的方差是否相等。F值越大，则认为两组方差越不相等。 3.Hartley测验Hartley测验与方差比的思维比拟相似，差异在于Hartley测验用于多组方差的测验，用多组中最大的方差除最小的方差，失去一个F值，而后通过F值的判断来对方差齐性进行判断。 4.Levene测验Levene测验是将每个值先转换为为该值与其组内均值的偏离水平，而后再用转换后的偏离水平去做方差分析，即组间方差/组内方差。 在这里对于组内均值有多种计算形式：平均数、中位数、截取平均数(去掉最大和最小值后求均匀)。 在Python中有现成的函数能够应用： from scipy.stats import levenestat, p = levene(x, y, z)print(stat, p)下面公式中x、y、z代表不同组的样本。 5.BF法Levene测验最开始计算组内均值的时候只是用了组内平均数，起初又有名叫Brown和Forsythe的两位前辈对齐进行了革新，增加了中位数和截取均值的办法，简称BF法。 这个在Python外面用的也是levene函数，通过调整参数的取值即可。 6.Bartlett测验Bartlett测验的核心思想是通过求取不同组之间的卡方统计量，而后依据卡方统计量的值来判断组间方差是否相等。该办法极度依赖于数据是正态分布，如果数据非正态分布，则的进去的后果偏差很大。 在Python中有现成的函数能够应用： from scipy.stats import bartlettstat, p = bartlett(x, y, z)print(stat, p)下面公式中x、y、z代表不同组的样本。 7.总结后面介绍了好几种办法，最初来总结下这几种办法的利弊及实用条件：方差比、Hartley测验、Bartlett测验都须要原始数据是正态分布，Levene测验和BF法对正态分布不是很依赖。比拟罕用的是Levene测验，实用于多组方差的比拟，且对正态性没要求。

明天给大家分享一种在数据分析过程中对于率指标剖析可能会犯的一种谬误。这个问题其实很多新人都会犯，有的老人也会犯，而且很多时候错了当前并不自知。刚好读者群有人在问相似的问题，所以就来写篇文章分享下。 先看个例子，如下展现了XXX公司各个渠道的留存率状况，当初如果想要看一下该公司总计的留存率状况应该怎么算呢？ 直观看上去应该有两种算法，第一种算法是用各个渠道所有的留存用户数÷各个渠道所有的新注册用户数，第二种算法是间接对三个渠道的留存率求一个平均值。那么这两种算法有啥区别呢？算进去的后果有啥不一样呢？如果你把上表中的数字用两种算法算一下，算进去的后果是不一样的。那到底哪种是正确的呢？ 如果你平时是用的第一种算法，那么祝贺你，你的做法是对的，然而第二种算法错在哪里了呢？这是因为不同渠道的新注册用户数是不一样的，所以对最初后果的影响水平也是不一样的，如果你间接对三个渠道的留存率求平均值，也就是你假如了这三个渠道最初对总留存率的影响是一样的，但显然是不一样的。所以这外面引出了第三种算法，即： 试着入手算一算，用第三种算法算进去的后果和第一种算法算进去的后果是一样的。 那如果不同渠道的新注册用户数是一样的状况下时，比方下表这样，这个时候用下面三种不同的算法算进去的后果都会是一样的。 以上就是对于率指标剖析常常会犯的一个谬误，其实下面这种状况不仅实用于率指标，精确的来说，应该是实用于所有须要分组相除的状况，比方每个班级的平均分和年级总平均分之间的关系。心愿对你有用。

还记得前段时间看过一篇文章，就是考察大家疫情期间都干了什么，有一条是疫情期间终于弄清楚了PDF和CDF的区别。PDF、PMF、CDF这几个概念的确很容易混同。明天就来捋一捋这几个概念。 1.基本概念PDF：是英文单词 probability density function 的缩写，翻译过去是指概率密度函数，是用来形容连续型随机变量的输入值，在某个确定的取值点左近的可能性的大小的函数。 PMF : 是英文单词 probability mass function 的缩写， 翻译过去是指概率品质函数，是用来形容离散型随机变量在各特定取值上的概率。 CDF : 是英文单词 cumulative distribution function 的缩写，翻译过去是指累积散布函数，又叫散布函数，是概率密度函数的积分，用来示意离散型随机变量x的概率分布。 总结一下就是下面三者的横轴都是随机变量x的取值，PDF的纵轴示意连续型随机变量x呈现的可能性(非概率)，PMF的纵轴示意离散型随机变量x呈现的概率，CDF的纵轴示意连续型随机变量x的概率。 置信大家看完下面的概念当前对这几个还是有点懵，接下来咱们就认真讲讲这些概念的前因后果。 2.频率散布条形图频率散布条形图次要用在离散数据中，横轴为一个个具体的点(类别)，纵轴为这些点对应的频率。 当试验次数足够多时，咱们能够用频率来代替概率，也就是能够把频率散布条形图中的纵轴当作每个类别呈现的概率值。此时的频率散布条形图就能够当作是PMF图。 3.频率散布直方图在频率散布直方图中横轴示意泛滥个连续变量离散化当前的区间，这个区间的大小称为组距，纵轴示意频率/组距。 上图中每个长方形的面积就是该区间的频率，即概率。 当长方形的宽度无限小，即组距无限小的时候，频率散布直方图就有限靠近于下方这样的润滑曲线，咱们把这条曲线叫做概率密度曲线，即PDF。 4.累积散布函数累计散布函数就是从上图中的概率密度曲线的最右边开始，而后逐步往右求取曲线下方的面积，即概率。 以上就是对于PDF、PMF、CDF三者之间的异同状况，如果对公式推导方面感兴趣的话能够间接上网搜寻即可。

咱们后面讲了异方差，也讲了怎么用图示法来判断是否有异方差，这一篇来讲讲怎么用统计的办法来判断有没有异方差。 对于测验异方差的统计办法有很多，咱们这一节只讲比拟广泛且比拟罕用的white test(怀特测验)。 假如当初咱们做了如下的回归方程： 如果要用怀特测验测验上述方程有没有异方差，次要分以下几个步骤： 1.step1：对方程进行一般的ols预计，能够失去方程的残差ui。 2.step2：以第一步预计预计进去的残差作为y，结构如下方程： 下面结构的方程看起来比较复杂，但次要是由三局部组成：原方程的解释变量、解释变量的平方、解释变量之间的交互项。 方程结构好当前对方程进行预计求解。 3.step3：再回忆一下什么是异方差，就是残差项与某一个或某一些x之间有相关性是不是。 那如果step2中的方程中每一个系数都为0，是不是阐明残差与任意x都是无关的，咱们把这个称为原假如；反之，只有有一个系数不为0，就阐明残差与x无关，也就是存在异方差，咱们把这个称为备择假如。 在原假如成立的状况下，能够得悉step2中方程的R^2乘以样本容量n遵从自由度等于step2回归方程中的变量数的卡方散布。 在遵从卡方散布的前提下就能够依据与卡方散布的临界值来比拟来判断原假如是否成立。 4.step4：如果计算出来的nR^2显著高于选定显著性程度(p_value值)的卡方临界值，则须要回绝原假如，也就是方程存在异方差。 如果存在异方差时，还能够查看step2方程的预计后果中每个变量的显著性状况，进而确定是哪个变量引起的异方差。 须要留神的是，如果模型中蕴含多个变量时，此时引进多个变量的交互项会大大降低方程的自由度，所以看状况能够抉择不加。 当然，以上过程也不须要咱们本人去实现，Python也是有现成的包能够调用： statsmodels.stats.diagnostic.spec_white(resid,exog)resid示意原方程的残差，exog示意要构step2中的方程模式。通过下面的函数最初会输入卡方值、对应的p_value以及自由度。 对于异方差更多的内容，能够点击文章结尾的专辑局部查看。

咱们在后面的方差分析中有提过一个概念就是自由度，在后面文章中给了一个计算就是自由度=样本数-1。这一篇就来具体聊聊什么是自由度。 先来看看百度百科的解释： 自由度(degree of freedom, df)指的是计算某一统计量时，取值不受限制的变量个数。通常df=n-k。其中n为样本数量，k为被限度的条件数或变量个数。下面加粗的局部其实就是对于自由度的外围解释了。再给大家举个例子： 假如当初有三个变量x1、x2、x3，且这三个变量之间没有任何分割，那么这三个变量的取值都是独立的、不受限制的、互不烦扰的。这个时候自由度就是3，因为有3个变量的取值不受限制。 如果咱们给下面这三个变量加一个限度条件，就是x1+x2+x3=0，这个时候这三个变量的取值就不能轻易了，前两个变量的取值能够轻易点，然而第三个变量的取值就受前两个变量取值的限度，所以此时的取值不受限制的变量个数变成了2，也就对应的自由度变成了2。 了解了自由度的外围原理当前咱们来看看自由度的次要利用场景： 1.方差第一个场景就是总体方差和样本方差，咱们晓得总体方差的分母是n，而样本方差的分母是n-1，这是因为在计算样本方差时须要用到样本均值，如果样本均值已知了，那么组成样本的n个样本中就会有一个样本的取值受到限制。此时的自由度就变成了n-1。 再想一下方差的概念，方差其实看的是n个样本的均匀稳定水平，也就是由这n个样本一起导致的稳定有多大。而样本方差中理论可能决定稳定的只有n-1个样本，所以就除n-1。 2.回归在回归方程中也波及到自由度的问题，假如当初有n个x变量，因为这n个x形成了一个方程，这个方程就是一个约束条件，此时能够自在变换的变量就是n-1个，对应的自由度也就是n-1。 以上就是对于自由度的一个简略介绍，大家好好了解了解。

明天这篇来讲讲加权最小二乘法(WLS)，加权最小二乘是在一般的最小二乘回归(OLS)的根底上进行革新的，次要是用来解决异方差问题的。 OLS的惯例模式如下： 咱们在后面讲过OLS有几个根本假设，其中一个就是ui是随机烦扰项，即随机稳定的，不受其余因素的影响，即在x取不同值时var(ui)都是一个固定的常数。但有的时候ui不是随机烦扰项，而是与x的取值无关的，比方在钻研年龄和工资收入的之间的关系时，随着年龄越大，ui的稳定是会越大的，即var(ui)不是常数了，这就是呈现了异方差。此时的数据不满足OLS的根本假设，所以如果间接应用OLS进行预计，会使预计进去的后果是有偏的。 如果咱们在预计的时候能够把不同x的对应的ui的大小思考进去的话，失去的后果应该就是ok的。那咱们应该如何思考进去呢？ 假如不同x对应的ui的稳定(方差)为i^2，咱们在OLS根本方程左右两边同时除i，最初失去如下后果： 为了让方程看起来更加相熟一点，咱们再做一个变换： 变换后的方程是不是就和一般的OLS的方程模式是一样的了，此时的方程也满足根本的OLS假设，因为咱们把不同x对应的i给除掉了。就能够利用一般OLS方程的办法进行求解了。咱们把这种变换后的方程称为WLS，即加权最小二乘法。 尽管整体思路上没啥问题了，然而这里还有一个关键问题就是i怎么获取呢？ 先用一般最小二乘OLS的办法去预计去进行预计，这样就能够失去每个x对应理论的残差ui，而后将ui作为i。1/ui作为权重在原方程左右两边相乘，将失去的新的样本值再去用一般最小二乘预计即可。 以上就是对于加权最小二乘的一个简略介绍。

上一篇文章咱们介绍的工夫预测的办法根本都是通过历史数据间接求均匀算进去的的。这一篇讲一些用模型来预测的办法。 1.AR(p)模型先讲第一个AR模型，AR的全称是Auto Regression，示意自回归，大家应该都晓得一般的回归方程，都是用x去回归y，这里的x和y个别不是同一个货色。而咱们这里的自回归顾名思义就是用本人回归本人，也就是x和y都是工夫序列本人。具体的模型如下： 下面模型中，Xt示意t期的值，当期的值由前p期的值来决定，值是常数项，相当于一般回归中的截距项，是随机误差，因为当期值总有一些因素是咱们没思考进去的，而这些因素带来的的当期值的扭转，咱们就把它归到局部中。 AR模型与咱们后面讲过的加权均匀之间的区别就是多了常数项和误差项。 2.MA(q)模型MA的全称是Moving Average，示意挪动均匀。具体模型如下： 下面模型中，Xt示意t期的值，当期的值由前q期的误差值来决定，值是常数项，相当于一般回归中的截距项，ut是当期的随机误差。MA模型的核心思想是每一期的随机误差都会影响当期值，把前q期的所有误差加起来就是对t期值的影响。 3.ARMA(p,q)模型ARMA模型其实就是把下面两个模型进行合并，就是认为t期值不仅与前p期的x值无关，而且还与前q期对应的每一期的误差无关，这两局部独特决定了目前t期的值，具体的模型如下： 4.ARIMA(p,d,q)模型ARIMA模型是在ARMA模型的根底上进行革新的，ARMA模型是针对t期值进行建模的，而ARIMA是针对t期与t-d期之间差值进行建模，咱们把这种不同期之间做差称为差分，这里的d是几就是几阶差分。 还是拿gdp数据为例，下图就是一阶差分以及一阶差分当前的后果： 下图为一阶差分前后的gdp趋势图，能够看出理论gdp值为持续上升趋势，差分后变成了随机稳定： ARIMA的的具体模型如下： 下面公式中的wt示意t期通过d阶差分当前的后果。咱们能够看到ARIMA模型的模式根本与ARMA的模式是统一的，只不过把X换成了w。 5.最初当数据是安稳工夫序列时能够应用后面的三个模型，当数据是非安稳工夫序列时，能够应用最初一个，通过差分的形式将非安稳工夫工夫序列转化为安稳工夫序列。 以上就是罕用的对工夫序列预测的统计模型。

明天给大家分享两个概念，比例和比率。 前两天发过，发了当前有读者反映有点瑕疵，所以删除了重发。 比例和比率，乍一看下来，如同这两个指标没啥区别，都是用来示意比的，但实际上两者不止概念有些差异，利用场景也不太一样。 比例用来反映一个整体中各局部之间的组成状况，个别用 a ：b 的模式体现，比方东南西北四个区的贷款数量之间的比例为：35:30:20:15，这四局部组成了全国这一个整体。 独身群体中，男女比例为1:2，这也是比例。 比率则用来反映组成总体的某一部分在总体中的一个占比状况，个别用百分比来示意。比方坏账率就是总贷款量中的坏账量在总贷款量中的一个占比。每个区域的坏账率就是每个区域内坏账量在这个区域内总贷款量的一个占比。东南西北四个区的坏账率别离为15%、20%、30%、35%。如下图所示： 坏账率 = 坏账量/总贷款量。 男生群体中有50%的人是独身，这也是比率。 当初总共有100笔坏账，其中东南西北四个区各自区域的坏账比例为：50:25:15:10。东区的坏账量在全国的坏账量外面比例是最高的，然而能说东区是全国坏账最重大的中央吗？显然不太能。咱们还须要看一下这100笔坏账是来自于哪些贷款的,即每个分区的坏账是基于多少贷款量产生的，也就是看一下各自区域内的坏账比率，下图所示： 通过上图能够发现，尽管东区的坏账量在全国坏账量外面的比例是最高的，然而坏账率是全国四个区外面最低的，之所以坏账量占比高是因为总贷款量基数比拟大。 其实坏账率和贷款量之间始终是一个博弈的过程，要想有更多的贷款量，就须要把审核门槛升高，可是升高审核门槛就意味着坏账率将会很大概率升高。 所以在日常剖析过程中，首先要分明剖析的目标，而后依据理论状况应用比例或比率或两者联合同时应用，不能想当然的以比例或比率得出结论。

咱们在后面讲过数据的正态性测验，介绍了测验数据是否正态的两种办法。这一节咱们来看一下，如果数据不满足正态时该怎么办，答案就是将非正态数据通过Box-Cox变换进一步转换成合乎正态分布的数据。这一篇就给大家分享下Box-Cox变换的具体内容。 Box-Cox变换是多种变换的总称，具体的公式如下： 下面公式中y()示意变换后的值，依据的值不同，属于不同的变换，当值取以下特定的几个值时就变成了非凡的数据变换： 当=0时，Box-Cox变换就变成了对数变换，y() = ln(y)；当=0.5时，Box-Cox变换就变成了平方根变换，y() = y^1/2当=1时，Box-Cox变换变换就是它自身，y() = y当=2时，Box-Cox变换就变成了平方变动，y() = y^2当=-1时，Box-Cox变换就变成了倒数变动，y() = 1/y。值除了能够抉择上述特定的值以外，还能够抉择其余值，那当咱们拿到一份非正态数据时，咱们应该取值等于多少对齐进行变换呢？这个又该怎么定呢？ 值取多少，咱们能够利用Python中现成的函数，让函数主动去摸索，而后返回给咱们最优的值是多少就能够。这个函数就是boxcox_normmax，这个函数用来计算给定的非正态数据对应的最优值。 boxcox_normmax(x[, brack, method])参数：    x：非正态数据    brack： 值搜寻距离，默认即可    method：计算值的办法，有pearsonr、mle、all三种可选，默认为pearsonr，即依照相关性的办法去计算，如果选all，则会返回各种办法的计算结果返回值：    返回值当咱们失去最优的值当前，就能够依据值进行数据转换了，这个时候能够用另外的一个函数boxcox，这个函数是依据指定的值对原始数据进行转换。 boxcox(x[, lmbda, alpha])参数：     x：非正态数据    lambda：转换的值    alpha：计算置信区间时所用到的alpha值返回值：    boxcox：通过转换当前的数据    maxlog：如果在传入时lambda参数值没有指定的话，该函数也会计算一个值进去    (min_ci, max_ci)：如果lambda参数为空且alpha参数不为空时，会计算maxlog的一个置信区间进去咱们下面讲了计算值有不同的办法，那到底哪种办法计算出来的值更加牢靠一些呢？咱们能够通过另外一个函数boxcox_normplot来查看到底哪种办法计算出来的值更牢靠。 boxcox_normplot(x, la, lb, plot=None, N=80)参数：    x：非正态数据    la,lb：值的上下界    plot：绘图的画布    N：横轴的坐标点个数返回值：    lmbdas：通过box-cox算进去的多个值    ppcc：相关系数，能够了解成值的牢靠水平以上就是box-cox变换过程中用到的三个不同的函数，接下来咱们给大家理论演示一下这三个函数如何应用。 首先，咱们导入一份非正态数据，并绘制这份数据的概率密度图，须要这份数据的在公众号后盾回复非正态数据，即可取得。 import pandas as pdimport numpy as npimport seaborn as snsdf = pd.read_excel(r"非正态数据集.xlsx")sns.distplot(df["price"],color = "#D86457") 通过下面的概率密度图，咱们能够看出这是一份偏态数据，也就是非正态。接下来咱们先利用boxcox_normmax函数来寻找最优值，代码如下： from scipy import statsstats.boxcox_normmax(df["price"])---返回：0.17896037184755484在取得最优值当前，咱们再利用boxcox函数来进行数据转换，具体代码如下： x = stats.boxcox(df["price"],stats.boxcox_normmax(df["price"]))sns.distplot(x,color = "#D86457") 对转换后的数据再次进行概率密度图的绘制，咱们能够看到，数据就很正态了。 接下来再来咱们再看一下咱们计算出来的值是不是最优的，具体代码如下： fig = plt.figure()ax = fig.add_subplot(111)stats.boxcox_normplot(df["price"], -20, 20,plot = ax)plt.axvline(x = stats.boxcox_normmax(df["price"]),color = "#D86457")plt.show()两头红色那条线的地位就是咱们求进去最优的值，后果很吻合。 以上就是对于Box-Cox变换的实践和实战内容，大家多多练习。

明天咱们来聊聊统计学中的偏态散布，聊偏态散布以前咱们先看看正态分布，上面这张图在公众号文章中屡次呈现，就是传说中的正态分布。 这张图中的横轴是随机变量 x 的具体值，正态分布的中心点是随机变量 x 的均值 ，以均值为核心，而后向两边扩散，既然是均值，那必定就有比均值大的值，也有比均值小的点，咱们用标准差 示意数据集的离散水平，也就是间隔均值 的远近。 纵轴是 x 对应的概率密度。咱们应该都晓得概率，是用来示意一个值或一种状况呈现的可能性大小。而概率密度等于一段区间(随机变量 x 的取值范畴)的概率除以该段区间的长度。 横轴与纵轴围成的面积示意横轴 x 对应的这个区间呈现的概率。 x 轴标记出了 7 个点，别离为:、u+、u-、u+2、u-2、u+3、u-3，即间隔均值1倍、2倍、3倍、3倍以上标准差的间隔。 能够看到有64.2%(34.1+34.1)的数据集中在(u-,u+)之间，有27.2%的数据位于(u±,u±2)之间,有4.2%的数据位于(u±2,u±3)，剩下的就是(u±3，∞)。阐明大部分数据还是集中在平均值左近的，而咱们生存中的很多事件都是合乎正态分布的，这也就是为什么能够用平均值来代替整体程度的一个起因，比方均匀身高、平均工资等等。 尽管大多数状况下数据是正态分布的，然而也有不是正态分布的状况，这个时候就是偏态散布了，偏态散布有两种，左偏和右偏。长尾在哪边就是哪篇，上面第一张图的长尾在右边就是左偏，最初一张图的长尾在左边就是右偏。 如果是左偏，阐明大多数是集中在左边的，即众数 > 中位数 > 均值；如果是右偏，阐明大多数是集中在右边的，即众数 < 中位数 < 均值。 咱们能够用偏态系数来掂量具体的偏离水平，偏态系数大于0则右偏，小于0则左偏，值越大越偏。 在 Python 中要计算某一列的偏态系数能够应用如下代码： #计算col列的偏态系数df["col"].skew()因为事实中很多数据是合乎正态分布的，很多模型也都是假如数据是遵从正太散布的，比方方差分析中，就是假如数据是遵从正态分布的。如果你的数据是偏态散布的时候，这个时候能够对数据进行转换，从偏态数据转换成正态数据，常见的转换就是原始数据取对数。 在 Python 中能够应用上面代码对数据取对数。 #对x取对数 import mathmath.log( x )统计学中为什么要对变量取对数：https://www.zhihu.com/questio...

后面讲了大数定理，讲了核心极限定理，有读者留言让讲讲切比雪夫定理，安顿。这一篇就来讲讲切比雪夫定理。 在讲切比雪夫定理之前，咱们先看下切比雪夫不等式： 其中P示意概率，X是随机变量，是冀望，k是常数，是标准差，整个公式示意间隔冀望越远的值呈现的概率是越小的。 再拿正态分布这张图来感触下，大部分值都是散布在均值左近的，离均值越远的值是越少的，对应呈现的概率也就越低。 对于不等式的证实，咱们就不证实了，有趣味的同学能够去理解下，咱们间接拿来用就好。 看完不了不等式，咱们再来看定理，其实是一回事的，切比雪夫定理示意： 在任意一个数据集中，位于其均值±m个标准差范畴内的数值比例至多为1－1/m2，其中m为大于1的任意负数。对于m=2，m=3和m=5有如下后果： 所有数据中，至多有3/4（或75%）的数据位于均值±2个标准差范畴内。所有数据中，至多有8/9（或88.9%）的数据位于均值±3个标准差范畴内。所有数据中，至多有24/25（或96%)的数据位于均值±5个标准差范畴内。 拿后面的正态分布为例，在均值±2个标准差范畴内的数据约占到全副的95%。 咱们来模仿生成两个不同散布(正态&非正态)的数据验证下： import numpy as npimport pandas as pdimport seaborn as snsimport matplotlib.pyplot as plt#生成正态数据norm_data = np.random.randn(1,990) #生成非正态数据x = np.arange(0.01,1,0.001)long_data = 1/xdata = pd.DataFrame({"norm_data":norm_data.reshape(990,),"long_data":long_data})#绘制概率分布图plt.figure(figsize = (8,8))plt.subplot(221)sns.distplot(data["norm_data"])plt.subplot(222)sns.distplot(data["long_data"])#将正态&非正态数据依照标准差进行切分norm_data_std_bin = [-np.inf                     ,data["norm_data"].mean() - 3*data["norm_data"].std()                     ,data["norm_data"].mean() - 2*data["norm_data"].std()                     ,data["norm_data"].mean() - 1*data["norm_data"].std()                     ,data["norm_data"].mean()                     ,data["norm_data"].mean() + 1*data["norm_data"].std()                     ,data["norm_data"].mean() + 2*data["norm_data"].std()                     ,data["norm_data"].mean() + 3*data["norm_data"].std()                     ,np.inf]long_data_std_bin = [-np.inf                     ,data["long_data"].mean() - 3*data["long_data"].std()                     ,data["long_data"].mean() - 2*data["long_data"].std()                     ,data["long_data"].mean() - 1*data["long_data"].std()                     ,data["long_data"].mean()                     ,data["long_data"].mean() + 1*data["long_data"].std()                     ,data["long_data"].mean() + 2*data["long_data"].std()                     ,data["long_data"].mean() + 3*data["long_data"].std()                     ,np.inf]data["norm_data_cut"] = pd.cut(data["norm_data"],bins = norm_data_std_bin)data["long_data_cut"] = pd.cut(data["long_data"],bins = long_data_std_bin)plt.subplot(223)(data["norm_data_cut"].value_counts().sort_index()/data["norm_data_cut"].count()).plot(kind = "bar",rot = 30)plt.xticks(np.arange(0,8),["[-inf,u-3]","[u-3,u-2]","[u-2,u-]","[u-,u]","[u,u+]","[u+,u+2]","[u+2,u+3]","[u+3,+inf]"])plt.subplot(224)(data["long_data_cut"].value_counts().sort_index()/data["long_data_cut"].count()).plot(kind = "bar",rot = 30)plt.xticks(np.arange(0,8),["[-inf,u-3]","[u-3,u-2]","[u-2,u-]","[u-,u]","[u,u+]","[u+,u+2]","[u+2,u+3]","[u+3,+inf]"])通过运行下面的代码能够失去如下四张图： 第一行是正态&非正态数据的概率分布，第一张是完满的正态分布，第二张是长尾散布。 第二行是正态&非正态数据中均值±m个标准差范畴内的数据占比，能够看到第一张图中的数据占比与咱们后面的正态分布示意图中是统一的，第二张图因为是长尾散布，所以大部分数据都集中在了均值均值±1个标准差范畴内。 综上，不论是正态分布还是非正态分布，随机变量的散布状况都是满足切比雪夫定理的。这就像，有人说他月薪不超过100w一样。在大多数状况下都是正确的。 切比雪夫定理的一个利用场景就是用来对数据进行预估，比方你当初晓得一个群体支出的均值和标准差，而后想要依据均值和标准差得出这个群体的整体支出状况，比方90%的人的支出是多少、80%的人的支出是多少？这个预估问题应该怎么算呢？ 如果你曾经确切的晓得了这个群体的支出是合乎正态分布的，那就简略了，咱们晓得正态分布中的数据是均匀的散布在均值两侧的，90%的人会有45%的人小于均值，另外45%的人大于均值。 可现实情况中，并不是所有的数据都是合乎正态分布的，也并不能够晓得所有数据的实在散布状况，这个时候就能够用切比雪夫定理。要预估90%的人的支出问题，只须要让1-1/m2等于90%，即可求出m值，通过m值就能够晓得90%的人的支出状况。 如果晓得具体的散布，能够用具体的散布去进行预计，这样必定更加精确，然而如果不晓得具体散布的时候，能够用切比雪夫，尽管不是很准确，然而总比闭着眼睛猜要靠谱点。

后面咱们讲过核心极限定理。这一节来讲讲大数定理，大数定理和核心极限定理是比拟靠近的两个概念，这两个定理常常一起呈现。咱们来具体看下大数定理的内容： 大数定律是指：随着样本容量n一直减少，样本平均数将越来越靠近于总体平均数(冀望 )，咱们把总体的平均数称为冀望，对于均值与冀望的差异。 基于大数定理的存在，所以咱们日常剖析过程中个别都会应用样本的均值来预计总体的均值。比方大家所熟知的试验，其实就是拿总体中的局部样本去做试验，而后在局部样本上失去的均值成果就能够等效代替是在全副样本上失去的成果。 不过须要留神的是，咱们下面说到的是随着样本数的减少，样本均值会越来越靠近总体样本均值，靠近不代表等于，所以样本均值和总体还是会有一些偏差的，但在理论业务中咱们个别又无奈拿到总体的均值，所以只能用样本均值，然而要晓得还是有一些偏差的。 接下来，咱们用数据模仿下： 咱们先随机生成10w个值，把这10w个值作为咱们的总体，而后随机从这10w外面抽取100、200、300 …… 99900、100000，针对每次抽取进去的样本计算一个均值，最初会失去99900个均值，咱们把这些均值依照样本容量从小到大排序，最初绘制出均值趋势图如下：上图中的红线是代表总体均值，能够看出，随着样本容量n一直减少，样本均值的稳定幅度越来越小，越靠近于总体均值。下面过程的Python实现代码如下： import numpy as npimport pandas as pdall_value = np.random.randint(1,100000,100000)sample_size = []sample_maen = []for i in range(100,100000,100):    sample_size.append(i)    sample_maen.append(np.random.choice(all_value,i).mean())pd.DataFrame({"sample_size":sample_size,"sample_maen":sample_maen}).set_index("sample_size").plot()plt.axhline(all_value.mean(),color = "red")大家能够把代码复制下来，本人运行一遍。

咱们后面讲过方差分析，方差分析的利用场景是什么样子的呢？不记得同学能够翻回去看看。当咱们要比拟两组或者多组均值有没有显著性差别的时候，咱们能够用方差分析。请留神，这外面咱们提到是两组或者多组之间的均值比拟时，咱们用方差分析，想一下什么类型的数据能够求均值呢？是不是只有数值类型的数据才能够求均值。也就是所谓的连续型变量。那如果咱们要比拟两组或者多组之间的分类型变量之间是否有显著性差别呢？这个时候就不能够应用方差分析了，就须要应用专门用于分类变量比拟的卡方测验。 接下来咱们具体看一下卡方剖析是怎么做的。 当初某个钻研机构为了验证一下吸烟与肺病的关系，通过抽样调查失去如下数据： 咱们先假如是否吸烟与是否患肺病之间是没有必然联系的，也就是不论是否患肺病的群体中吸烟者比例都应该等于共计中吸烟者比例，即33%。咱们来看一下，如果各组的吸烟者比例都为33%的时候，各组的人数散布状况是什么样的。咱们通过上表能够看出肺病患者外面的吸烟比例为48%，显著高于非肺病患者中的吸烟比例20%。可是这能间接阐明两者之间有显著性差别吗？咱们须要来验证一下到底显著不显著呢？那具体该怎么验证呢？ 通过比照后面的两个表，咱们能够发现各组的人数都不太一样，造成不太一样的起因次要有两个，一个就是抽样误差导致的，另一个就是咱们的假如是谬误的，也就是各组之间的数据原本就是有差别的。那咱们怎么来判断到底是哪种谬误呢？这个时候就须要引入卡方测验了。 Ai为理论频数(呈现的次数)，Ti为实践频数。 咱们把第一个表中各组的值称为理论频数，把第二个表中各组的值称为实践频数。卡方测验的值用来反映实践频数和理论频数的差别大小。实践频数和理论频数差异越大(分子越大)，卡方测验值越大；反之，卡方测验值越小。 如果只是因为抽样误差造成的理论频数和实践频数的差别，那卡方测验的值应该很小，因为咱们置信咱们的抽样还是比拟正当的，所以误差不会特地大；如果卡方测验值太大，就不太可能用误差来解释，只能阐明原假如不成立，即各组之间的数据原本就有差别。 咱们在下面的形容中用到了两个词，卡方值很小或太大，什么样的卡方值算很小，什么样的卡方值算太大呢？这个时候就须要引入咱们的卡方散布了，如下图所示，就和Z测验中的正态分布一样。 上图中的n为自由度，不同自由度对应的卡方散布是不一样的。而自由度又与特色维度无关，自由度 = (行数-1)*(列数-1)，咱们下面的例子是两行两列的数据，所以最初自由度为1。咱们晓得了自由度当前，就能够通过卡方散布的临界值表去找到这个自由度对应的不同边界值以及P值。 通过下图能够看出，当自由度为1时，临界值3.84对应的P值为0.05，也就是当卡方值的大于3.84时，右侧面积小于0.05，能够认为是小概率事件，不可能产生。 卡方散布的临界值表： https://wenku.baidu.com/view/... 咱们计算后面提到的两个表的卡方值： 计算出来的卡方值60.53远远大于3.84，所以能够认为咱们的原假如是不成立的，即是否患肺病与是否吸烟是有关系的。 以上就是对于卡方测验的一个整体过程。

1 前言&概述这篇文章是基于这篇文章的更新，次要是更新了一些技术栈以及开发工具的版本，还有修复了一些Bug。 本文是SpringBoot+Android+MySQL的增删查改的简略实现，用到的技术包含Jackson、OkHttp、bouncycastle、Spring Data JPA。 2 环境Android 4.1.2IDEA 2020.3.1Spring Boot 2.4.2MySQL 8.0.23OpenJDK 11环境筹备就略过了，须要的能够参考这里。 3 后端3.1 新建我的项目 依赖： 3.2 我的项目构造 3.3 实体类@Entity@Getter@Setter@NoArgsConstructor@AllArgsConstructorpublic class User { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Integer id; private String name; private String password;}根本的Lombok注解+JPA中的两个注解： @Id：标识主键@GeneratedValue：主键生成策略，包含四个主键生成策略如下： GenerationType.TABLE：应用一个特定的数据库表格来保留主键，不依赖外部环境和数据库的具体实现，然而不能充分利用数据库个性，个别不会优先应用，且个别配合@TableGenerator应用GenerationType.SEQUENCE：一些数据库不反对主键自增（如Oracle），这时就能够应用SEQUENCE，只有局部（Oracle/DB2/PostgreSQL）反对序列对象，个别不用于其余数据库GenerationType.IDENTITY：个别意义上的主键自增长，插入数据时主动给主键复制，比方MySQL中的auto_incrementGenerationType.AUTO：主键生成策略交给长久化引擎，长久化引擎会依据数据库在以上三种主键策略中抉择其中一种，这是JPA默认的主键生成策略3.4 长久层继承CrudRepository<T,ID>，T为实体类，ID为主键类型： @Repositorypublic interface UserRepository extends CrudRepository<User,Integer> { boolean existsByName(String name); User findByNameAndPassword(String name,String password);}一个须要留神的点是CrudRepository<T,ID>继承了Repository<T,ID>，而后者有一个叫查询方法的个性，就是说能依据一些办法中指定的关键字去生成对应的SQL，比方第一个办法existsByName，就依据name判断用户是否存在，参数为一个String name，返回boolean，具体的关键字以及例子参考如下： 3.5 业务层@Transactional@Service@RequiredArgsConstructor(onConstructor = @__(@Autowired))public class UserService { private final UserRepository repository; public boolean exists(User user){ return repository.existsByName(user.getName()); } public User findByNameAndPassword(User user){ return repository.findByNameAndPassword(user.getName(),user.getPassword()); } public boolean insert(User user){ repository.save(user); return true; } public boolean update(User user){ if(repository.findById(user.getId()).isEmpty()){ return false; } repository.save(user); return true; } public boolean deleteById(int id){ if(!repository.existsById(id)){ return false; } repository.deleteById(id); return true; }}注解解释如下： ...

1 前言&概述这篇文章是基于此处文章的更新，更新了一些技术栈，更加贴近理论须要，以及修复了若干的谬误。 这是一个前端Android+后端Java/Kotlin通过Servelt进行后盾数据库（MySQL）交互的具体步骤以及源码实现，技术栈： Android根底原生JDBC+原生ServletTomcat+MySQL（Docker）当然当初的很多Java后端开发都应用了Spring Boot而不是原生的Servlet，所以应用Spring Boot实现的能够笔者的另一篇文章。 只管基于Spring Boot实现十分的简便，然而应用原生的Servlet更能了解底层的原理。另外本篇文章是偏根底向的教程，很多步骤都会比拟具体而且附上了图，好了废话不说，注释开始。 2 环境Android Studio 4.1.2IntelliJ IDEA 2020.3MySQL 8.0.23Tomcat 10.0Docker 20.10.1服务器CentOS 8.1.19113 环境筹备3.1 IDE筹备官网装置Android Studio+IDEA，这部分就省略了。 3.2 MySQL3.2.1 装置概述这里的MySQL若无非凡阐明指的是MySQL Community。 首先，在Windows下，MySQL提供了exe安装包： macOS下提供了dmg安装包： 能够戳这里下载。 Linux下一般来说MySQL装置有如下形式： 软件包装置（apt/apt-get、yum、dnf、pacman等）下载压缩包装置源码编译装置Docker装置其中绝对省事的装置形式为Docker装置以及软件包装置，其次是压缩包形式装置，特地不倡议源码装置（当然如果喜爱挑战的话能够参考笔者的一篇编译装置8.0.19以及编译装置8.0.20）。 3.2.2 装置开始这里笔者本地测试抉择的是应用Docker装置，步骤能够查看这里。 另外对于服务器，也能够应用Docker装置，如果应用软件包装置的话，这里以笔者的CentOS8为例，其余零碎的参考如下： FedroaRedHatUbuntu3.2.2.1 下载并装置增加仓库： sudo yum install https://repo.mysql.com/mysql80-community-release-el8-1.noarch.rpm禁用默认MySQL模块（CentOS8中会蕴含一个默认的MySQL模块，不禁用的话没方法应用下面增加的仓库装置）： sudo yum module disable mysql 装置： sudo yum install mysql-community-server 3.2.2.2 启动服务并查看初始化明码启动服务： systemctl start mysqld查看长期明码： sudo grep 'temporary password' /var/log/mysqld.log 输出长期明码登录： mysql -u root -p批改明码： alter user 'root'@'localhost' identified by 'PASSWORD'3.2.2.3 创立内部拜访用户不倡议在Java中间接拜访root用户，个别是新建一个对应权限的用户并进行拜访，这里就为了不便就省略了。 ...

01.前言后面咱们讲过了多元线性回归。这一篇咱们来讲讲逐步回归。什么是逐步回归呢？就是字面意思，一步一步进行回归。 咱们晓得多元回归中的元是指自变量，多元就是多个自变量，即多个x。这多个x中有一个问题须要咱们思考，那就是是不是这多个x都对y有作用。答案就是有的时候都管用，有的时候局部管用。那对于那些没用的局部咱们最好是不让它退出到回归模型外面。咱们把这个筛选起作用的变量或者剔除不起作用变量的过程叫做变量抉择。 咱们刚提到自变量有用没用，那怎么来评判一个自变量到底有用没用呢？判断根据就是对自变量进行显著性测验。具体方法是将一个自变量退出到模型中时，有没有使残差平方和显著缩小，如果有显著缩小则阐明这个变量是有用的，能够把这个变量退出到模型中，否则阐明时无用的，就能够把这个变量从模型中删除。有没有显著缩小的判断规范就是依据F统计量来判断。 对于判断F统计量的显著性咱们在方差分析外面讲过，大家能够去看看。 变量抉择次要有：向前抉择、向后踢出、逐步回归、最优子集等，咱们这一篇次要讲前三种。 02.向前抉择向前抉择能够了解成从零开始抉择，因为模型最开始的时候是没有自变量的，具体的步骤如下： Step1：拿现有的k个变量别离和y建设回归模型，最初会失去k个模型以及每个模型中变量对应的F统计量和其p_value，而后从显著的模型中挑选出F统计量最大模型对应的自变量，将该自变量退出到模型中，如果k个模型都不显著，则抉择完结。 Step2：通过第一步咱们曾经失去了一个显著性变量，并把这个变量退出到了模型中。接下来再在曾经退出一个变量的模型外面持续别离退出剩下的变量，可能失去k-1个模型，而后在这k-1个模型外面筛选F值最大且显著的变量持续退出模型。如果没有显著变量，则抉择完结。 反复执行下面两步，直到没有显著性变量能够退出到模型为止，这就是向前抉择。 03.向后剔除向后剔除是与向前抉择绝对应的办法，是向前抉择的逆办法，具体的步骤如下： Step1：将所有的自变量都退出到模型中，建设一个蕴含k个自变量的回归模型。而后别离去掉每一个自变量当前失去k个蕴含k-1个变量的模型，比拟这k个模型，看去掉哪个变量当前让模型的残差平方和缩小的起码，即影响最小的变量，就把这个变量从模型中删除。 Step2：通过第一步咱们曾经删除了一个无用的变量，第二步是在曾经删除一个变量的根底上，持续别离删除剩下的变量，把使模型残差平方和缩小最小的自变量从模型中删除。 反复下面的两个步骤，直到删除一个自变量当前不会使残差显著缩小为止。这个时候，留下来的变量就都是显著的了。 04逐步回归逐步回归是向前抉择和向后踢除两种办法的联合。是这两种办法的穿插进行，即一遍抉择，一边剔除。 逐步回归在每次往模型中减少变量时用的是向前抉择，将F统计量最大的变量退出到模型中，将变量退出到模型中当前，针对目前模型中存在的所有变量进行向后剔除，始终循环抉择和剔除的过程，直到最初减少变量不可能导致残差平方和变小为止。 对于逐步回归的Python实现，网上有很多现成代码的，只有原理分明了，代码就很好懂了。

01.前言后面咱们讲了一元线性回归，没看过的能够先去看看：[一元线性回归剖析]。这一篇咱们来讲讲多元线性回归。一元线性回归就是自变量只有一个x，而多元线性回归就是自变量中有多个x。 多元回归的模式如下： 02.参数估计多元回归方程中各个参数也是须要预计的，对于为什么要预计，其实咱们在一元线性回归外面也讲过。与一元线性回归不同的是，一元线性回归拟合的是一条线，而多元回归拟合的是一个面。应用的办法也是最小二乘法。 03.拟合水平判断在多元回归外面拟合水平判断与一元回归也相似，也次要有总平方和、回归平方和、残差平方和这三种。 多元回归外面也有R^2，R^2 = SSR/SST = 1 - SSE/SST。因为减少自变量的会升高残差SSE，进而导致R^2减少。 为什么退出新的变量会使SSE升高呢？因为每新退出一个新的变量，这个新的变量就会奉献一部分平方和，而这个平方和就是从残差外面分离出来的。 为了防止自觉减少自变量而导致失去一个虚高的R^2，优良的前辈们又想出了一个新的指标，即修改后的R^2。公式如下： 公式中的n为样本量的个数，k为自变量的个数，通过n和k来调整R^2，这样就不会呈现随着自变量个数的减少而导致R^2也跟着减少的状况。 咱们个别用调整后的R^2来判断多元回归的准确性。 除了R^2以外，咱们还能够应用标准误差来掂量回归模型的好坏。标准误差就是均方残差(MSE)的平方根，其示意依据各自变量x来预测因变量y的均匀预测误差。 04.显著性测验咱们在一元线性回归外面做过显著性测验，在多元回归外面也是同样须要做显著性判断的。 4.1线性关系测验线性关系测验就是测验y和多个x之间的关系是否显著，是总体显著性测验。 测验办法与一元线性回归统一，即咱们假如没有线性关系，而后对变量进行F测验，具体的具体介绍，参考一元线性回归中解说的。 4.2回归系数测验线性关系显著性测验是对多个变量的一个显著性判断，也就是说只有多个x中有一个x对y的影响是显著的，线性关系就是显著的。而回归系数测验是用来看每一个x对应的系数是否是显著的。要看某个变量的系数是否显著，假如这个变量的系数等于0，而后进行t测验判断显著性。 具体的t测验能够查看假设检验的内容：[统计学的假设检验]。 05.多重共线性多元回归与一元回归还有一个不同点就是，多元回归有可能会存在多重共线性。 什么是多重共线性呢？多元回归外面咱们心愿是多个x别离对y起作用，也就是x别离与y相干。但在理论场景中，可能x1与x2之间彼此相干，咱们把这种x变量之间彼此相干的状况称为多重共线性。多重共线性可能会让回归失去一个谬误的后果。 既然多重共线性的问题很重大，那咱们应该如何发现呢？最简略的一种办法就是求变量之间的相关性，如果两个变量之间高度相干，就能够认为是存在多重共线性。 对于存在多重共线性问题的变量，咱们个别会把其中一个舍弃。 以上就是对于多元回归的一个简略介绍，大家能够看到很多内容没有开展来讲，次要是因为这些货色在之前的文章都讲过了。如果没有看过的同学，能够去后面对应的文章翻翻。

1.回归模型简介咱们先来看一下什么是回归模型，以下解释来源于百度百科： 回归模型是一种预测性的建模技术，它钻研的是因变量（指标）和自变量（预测器）之间的关系。这种技术通常用于预测剖析，工夫序列模型以及发现变量之间的因果关系。回归模型最重要的两个利用场景就是预测剖析和因果关系剖析，比方咱们上学的时候学过的一元一次方程组y = kx + b就是一个最简略的回归模型，当咱们晓得一个x时，比方此时的x是月份，就能够通过方程求出这个这个x对应的y，这里的y能够是销量，这个通过x求取y的过程就是一个预测的过程。 回归模型次要分为一元线性回归和多元线性回归，这一节先给大家讲一下一元线性回归。 2.参数估计参数估计是做什么的呢？是预计什么参数呢？就是用来预计方程y = kx + b中的k和b的。可能有的人会有这样的疑难，为什么要预计呢？而不是间接去算。咱们在上学的时候是能够间接去算的，那是因为只有两个点，通过这两个点的直线是确定的，所以对应的参数也是固定的。 而在理论利用中，咱们的数据点往往都是多个，这多个点往往不在一条直线上，然而呢，咱们又心愿这些点尽可能的都在一条直线上，所以咱们须要找到这么一条直线，这条直线到每个数据点的间隔都很近(靠近于0)，这样咱们就能够用这条间隔每个点都尽可能近的直线来近似示意这些点的一个趋势。这条线对应的 k 和 b 就是咱们预计进去的参数。 咱们在找这一条直线的有一个准则，就是每个点到这条线的间隔尽可能的小，最初让所有点到直线的间隔最小，咱们把这种办法称为最小二乘法，最小二乘法是参数估计的一种办法。 对于最小二乘法的更多内容，大家能够自行学习。 3.拟合水平判断通过下面的参数估计，咱们曾经失去了一条能够反映数据点趋势的线，可是这条线到底准确度如何，也就是和理论数据点走势的拟合水平是怎么样的，咱们须要来判断一下。 这里介绍几个对于判断拟合水平的概念。 总平方和(SST)：理论值与其平均值之间间隔的平方和，能够了解为方差(而非理论方差)，用来反映理论值y稳定大小的。 回归平方和(SSR)：回归值(即预测进去的y值)与理论值均值之间间隔的平方和。这一部分变动是因为自变量的变动引起的，是能够由回归直线来解释的。 残差平方和(SSE)：回归值与理论值之间间隔的平方和。这一部分是除了自变量影响之外的其余影响因素造成的，属于不可解释局部。 SST = SSR + SSE， 上述公式外表理论值y的稳定状况由两局部因素决定，一部分是因为自变量x不一样导致的y的变动(回归平方和)，另一部分是因为除自变量以外的因素决定(残差平方和)。 咱们现实状况下，理论值y的稳定尽可能都可能都是因为自变量x变动引起的，而且这个占比越高越能够阐明咱们的回归直线拟合的好。咱们把这个指标称为 R^2 = SSR/SST。 R^2越大，阐明拟合度越好，介于[0,1]之间。 4.显著性测验通过后面的步骤参数也求进去了，也就是y = kx + b中的 k 和 b 求进去了，那咱们是不是就能够间接拿来用了呢？很显然不太能，为什么呢？因为你参数估计是依据你现有样本数据预计进去的，所以直线反映的也是现有数据状况下的趋势，这些数据的趋势是否代表全量数据的趋势呢？咱们须要测验一下，这就是显著性测验。 回归直线其实是用来反映 x 和 y 之间的线性关系的，所以咱们首先要测验的就是线性关系是否显著，那怎么来测验，还是用咱们之前讲过的假设检验的办法。 咱们先假如 x 和 y 之间是没有线性关系的，如果没有线性关系是不是k就等于0，那既然这样总平方和的的稳定是不是就齐全由残差平方和决定了，那是不是意味着 SSR/SSE 根本为0，这是咱们通过如果没有线性关系这个假如得进去的论断。 还是后面方差分析中提到的，平方和会随着样本数据的减少而减少，所以咱们就须要把平方和转换成均方，即平方和/自由度。 在一元线性回归中，回归平方和的自由度为1(即自变量的个数)，残差平方和的自由度为n-2。 统计量F =(SSR/1)/(SSE/(n-2)) =MSR/MSE。 依据样本数据计算得出F值，确定显著性程度，查显著性程度对应的F边界值，如果F>F边界值，则回绝原假如，否则不回绝原假如。 5.回归方程利用一元回归方差次要用来做预测，分为点预测与区间预测，点预测就是通过回归方程预测往年12月份的具体销量是多少；区间预测是通过回归方程失去往年12月份销量的范畴大略是在哪一区间内。 点预测比较简单，间接把x代入到方程中就能够得出后果。区间预测略微比较复杂一些，然而区间预测的实质还是咱们之前讲过的置信区间[聊聊置信度与置信区间]的求取，关键点就两个，一个是样本均值，一个是标准差。样本均值也比较简单，标准差的公式如下：

明天咱们来讲一下异方差，在异方差以前，咱们先讲一下与异方差相似另一个概念：同方差，那同方差又是什么呢？同方差 = 雷同 + 方差，顾名思义就是方差雷同。那方差又是什么呢？方差是用来反映数据的稳定状况的，方差雷同，阐明数据的稳定状况是雷同的。讲完了同方差，那什么是异方差，大家应该也就明确了，异方差就是方差不雷同。 为什么要探讨异方差呢，是因为咱们在回归剖析和方差分析中都是假如样本之间是同方差的。在方差分析中，同方差是各组之间的方差相等；在回归剖析中，同方差是指对于每一个样本点来说，随机误差的平方和(残差平方和)是一样的。咱们在回归局部给大家讲过，残差平方和是回归值与理论值之间间隔的平方和，这一部分是除了自变量X影响之外的其余影响因素造成的，所以咱们把这一部分误差叫做随机误差，如果不同样本点之间受随机误差的影响是一样的，则随机误差平方和就是一样的，也就是同方差，反之则是异方差。 如下图反映的就是同方差，也就是不同受教育年限群体之间工资稳定状况是雷同的。 下图反映的就是异方差，也就是不同受教育年限群体之间工资稳定是不同的，受教育年限越长，工资稳定会越大；受教育年限越短，工资稳定会越小。 理解完了什么是异方差当前，咱们来看一下如何看不同样本点之间到底是同方差还是异方差呢？这就波及到异方差的测验了。测验异方差有描述统计办法和专门的统计测验办法，咱们这里次要给大家分享一下描述统计办法——看残差图。 残差图是以残差平方和为纵坐标，个别以回归拟合值y作为横坐标，当然也能够以其余自变量x作为横坐标，以下为几种不同类型的残差图： 下面这种类型的残差图：随着横轴的变动，纵轴围绕着一条水平线在稳定，阐明数据之间是满足同方差性的。 下面这种类型的残差图：随着横轴的增大，纵轴的数值在变小，阐明不同样本之间点之间的方差是不一样的，即异方差。 下面这种类型的残差图：横轴和残差之间是二次关系，也是异方差。 对于下面的残差图如何绘制，咱们在前面的回归实操局部给大家一起解说。

后面咱们讲了方差分析，方差分析次要是用于多组均值比拟的，方差分析的后果是多组均值之间是否有显著性差别，然而这个显著性差别是整体的显著性差别，可是咱们并不知道具体是哪些组之间有显著性差别。所以就有了咱们明天的多重比拟，目标就是为了获取具体哪些组之间有显著差别。 多重比较法办法有很多种，这篇次要介绍一下比拟罕用的一种LSD，LSD是least significant difference的缩写，又称最小显著差别办法。 应用LSD办法的具体步骤为： 1.提出假如：H0：两组之间无差别；H1：两组之间有差别。2.计算测验统计量：两组均值之差的绝对值。3.计算LSD，公式为： t/2为t散布的临界值，通过查t散布表失去，其自由度为n-k，n为样本总数，k为因素中不同程度的程度个数；MSE为组内方差；ni和nj别离为第i个样本和j个样本的样本量。4.依据显著性程度做作出决策，如果均值之差的绝对值大于LSD，则回绝H0，否则不回绝H0。 接下来举个栗子，带着大家把下面的流程走一遍。 step1：提出如下假如。 假如1：H0：零售业与旅游业无差别；H1：零售业与旅游业有差别假如2：H0：零售业与航空业无差别；H1：零售业与航空业有差别假如3：H0：零售业与家电制造业无差别；H1：零售业与家电制造业有差别假如4：H0：旅游业与航空业无差别；H1：旅游业与航空业有差别假如5：H0：旅游业与家电制造业无差别；H1：旅游业与家电制造业有差别假如6：H0：航空业与家电制造业无差别；H1：航空业与家电制造业有差别step2：计算测验统计量，即各两组之间的均值之差的绝对值 假如1、2、3、4、5、6别离对应的均值之差绝对值为1、14、10、13、11、24step3：依据LSD公式计算每个假如对应的LSD值。 依据数据求获得到组内平方和MSE = 142.526，具体求取办法参考后面讲的方差分析；通过查t散布表，在=0.05以及自由度=n-k=23-4=19状况下，t/2=2.093；最初计算出不同假如对应的LSD值为13.90、14.63、14.63、15.13、15.13、15.80step4：作出决策。 假如1的均值之差绝对值1小于对应的LSD值13.90，所以不回绝假如H0，即不能认为零售业与旅游业有显著差别；假如2的均值之差绝对值14小于对应的LSD值14.63，所以不回绝假如H0，即不能认为零售业与航空业有显著差别；假如3的均值之差绝对值10小于对应的LSD值14.63，所以不回绝假如H0，即不能认为零售业与家电制造业有显著差别；假如4的均值之差绝对值13小于对应的LSD值15.13，所以不回绝假如H0，即不能认为旅游业与航空业有显著差别；假如5的均值之差绝对值11小于对应的LSD值15.13，所以不回绝假如H0，即不能认为旅游业与家电制造业有显著差别；假如6的均值之差绝对值24大于对应的LSD值15.80，所以回绝假如H0，即认为航空业与家电制造业有显著差别。以上就是对于多重比较法-LSD的一个简略介绍以及案例，心愿对大家有用。

01.前言在后面咱们讲过简略的单因素方差分析，这一篇咱们讲讲双因素方差分析以及多因素方差分析，双因素方差分析是最简略的多因素方差分析。 单因素剖析就是只思考一个因素会对要比拟的均值产生影响，而多因素剖析是有多个因素会对均值产生影响。 须要留神的是一个因素可能会有不同的程度值，即不同的取值。比方要判断某一款药对某种病症有没有成果，服用不同的剂量成果应该是不一样的，尽管因素都是服药这一个因素，然而不同的药剂量代表不同的程度。 双因素（多因素）方差分析又能够分为两种，一种是有交互作用的，一种是没有交互作用的。啥意思呢？什么是交互作用呢？ 比方咱们大家所熟知的，牛奶和药是不能够一起吃的，如果独自喝牛奶有助于身材蛋白质的补充，如果独自吃药能够有助于医治病症，然而牛奶和药同时吃就会把两者的作用对消掉。这种两者之间的相互作用就能够了解成是交互作用，当然了，有的时候交互是正向呢，有的时候是负向的。 02.无交互作用方差分析当初有如下一份不同品牌不同地区的产品销量数据表，想要看一下不同品牌和不同地区这两个因素是否对销量有显著性影响： 咱们先来看看无交互作用的双因素方差分析具体怎么做呢，所谓的无交互也就是假如品牌和地区之间是没有交互作用的，互相不影响，只是彼此独自对销量产生影响。 后面单因素方差分析中，咱们是用F值去测验显著性的，多因素方差分析也同样是用F值. F = 组间方差/组内方差。 对于没有交互作用的多因素，能够单纯了解为多个单因素。也就是你能够独自去看品牌对销量的影响，而后再独自去看地区对销量的影响。 那独自怎么看呢？这就回到了咱们后面讲过的单因素方差分析。 咱们先来计算品牌的组内平方和: SSA = (每个品牌的均值 - 全副销量均值)^2*每个品牌内样本数    = (344.20-328.45)^2*5 + (347.80-328.45)^2*5 + (337.00-328.45)^2*5 + (284.80-328.45)^2*5    = 13004.55咱们再来计算地区的组内平方和: SSB = (每个地区的均值 - 整体销量均值)^2*每个地区内样本数    = (339.00-328.45)^2*4 + (330.25-328.45)^2*4 + (339.25-328.45)^2*4 + (318.25-328.45)^2*4    = 2011.7接着咱们来计算全副平方和： SST = (每个值-总体均值)^2    = 17888.95除此之外还有一个平方和： SSE = SST - SSA - SSB这部分是除品牌和地区以外的其余因素所产生的，称为随机误差平方和。 有了平方和当前，咱们同样须要求取均方，而均方 = 平方和/自由度。 SST的自由度 = 总程度数 - 1 = 19SSA的自由度 = 品牌的程度数 - 1 = 3SSB的自由度 = 地区的程度数 - 1 = 4SSE的自由度 = SSA的自由度*SSB的自由度 = 12 平方和有了，自由度也有了，均方MS也就能够求进去了，接下来进入到最重要的F值求取， 品牌因素的F值 = SSA/SSE地区因素的F值 = SSB/SSE 最初能够通过查F值表取得在置信度为95%的状况下时的F边界值表，而后和理论的F值作比拟，最初做出是否显著的判断。如下表： 03.有交互作用方差分析某交通部门想要晓得高峰期与路段是否会对汽车的行车时间有影响，通过人工采集失去了如下数据： 本次剖析须要思考峰期与路段之间的交互作用，某些路段的峰期行车时间可能异样偏高或偏低等。 和无交互作用的多因素方差分析流程相似，咱们先计算峰期的平方和： SSA = (每个峰期内的均值-总体均值)^2*每个峰期内样本数    = (23.2-20.25)^2*10 + (17.3-20.25)^2*10    = 174.05再来计算路段的平方和： SSB = (每个路段内的均值-总体均值)^2*每个路段内样本数    = (22.4-20.25)^2*10 + (18.1-20.25)^2*10    = 92.45再来计算交互作用的平方和： SSAB = (每个路段&峰期内的均值-该路段内的均值-该峰期内的均值+总体均值)^2*每个区间内的样本数     = (25.4-23.2-22.4+20.25)^2*5 + (21-23.2-18.1+20.25)^2*5 + (19.4-17.3-22.4+20.25)^2*5 + (15.2-17.3-18.1+20.25)^2*5     = 0.05 接着计算全副平方和： SST = (每个值-总体均值)^2    = 329.75最初来计算误差平方和： SSE = SST - SSA - SSB - SSABSST的自由度 = 总样本数 - 1 = 19SSA的自由度 = 峰期数 - 1 = 1SSB的自由度 = 路段数 - 1 = 1SSAB的自由度 = SSA的自由度*SSB的自由度 = 1SSE的自由度 = SST的自由度 - SSA的自由度 - SSB的自由度 - SSAB的自由度 ...

大家好，我是公众号：java小杰要加油，明天来分享一个京东面试真题，也是这是我前阵子听我旁边高T（高，实在是高）面试候选人的时候问的一个问题，他问，你能说说 mysql的事务吗？ MVCC有理解吗？话不多说，间接开干事务定义及四大个性事务是什么？ 就是用户定义的一系列数据库操作，这些操作能够视为一个实现的逻辑解决工作单元，要么全副执行，要么全副不执行，是不可分割的工作单元。 事务的四大个性（简称ACID）： 原子性（Atomicity）：一个事务是一个不可分割的工作单位，事务中包含的操作要么都做，要么都不做。一致性（Consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。隔离性（Isolation）：一个事务的执行不能被其余事务烦扰。即一个事务外部的操作及应用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能相互烦扰.持久性（Durability）：指一个事务一旦提交，它对数据库中数据的扭转就应该是永久性的,接下来的其余操作或故障不应该对其有任何影响。事务中常见问题脏读（dirty read）：就是一个A事务即使没有提交，它对数据的批改也能够被其余事务B事务看到，B事务读到了A事务还未提交的数据，这个数据有可能是错的，有可能A不想提交这个数据，这只是A事务批改数据过程中的一个两头数据，然而被B事务读到了，这种行为被称作脏读，这个数据被称为脏数据不可反复读（non-repeatable read）：在A事务内，屡次读取同一个数据，然而读取的过程中，B事务对这个数据进行了批改，导致此数据变动了，那么A事务再次读取的时候，数据就和第一次读取的时候不一样了，这就叫做不可反复读幻读（phantom read）：A事务屡次查询数据库，后果发现查问的数据条数不一样，A事务屡次查问的距离中，B事务又写入了一些合乎查问条件的多条数据（这里的写入能够是update，insert，delete），A事务再查的话，就像产生了幻觉一样，怎么忽然扭转了这么多，这种景象这就叫做幻读隔离级别——产生问题的起因多个事务相互影响，并没有隔离好，就是咱们方才提到的事务的四大个性中的 隔离性（Isolation） 呈现了问题 事务的隔离级别并没有设置好，上面咱们来看下事务到底有哪几种隔离级别 隔离级别 读未提交（read uncommitted RU）： 一个事务还没提交时，它做的变更就能被别的事务看到读提交（read committed RC）： 一个事务提交之后，它做的变更才会被其余事务看到。可反复读（repeatable read RR）： 一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。当然在可反复读隔离级别下，未提交变更对其余事务也是不可见的。串行化（serializable ）： 顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。咱们来看个例子，更加直观的理解这四种隔离级别和上述问题脏读，不可反复读，幻读的关系 上面咱们探讨下当事务处于不同隔离级别状况时，V1,V2,V3别离是什么不同的值吧 读未提交 (RU)： A事务能够读取到B事务批改的值，即使B事务没有提交。所以V1就是200 V1 : 200V2 : 200V3 : 200读提交（RC）： 当B事务没有提交的时候，A事务不能够看到B事务批改的值，只有提交当前才能够看到 V1 : 100V2 : 200V3 : 200可反复读（RR）： A事务屡次读取数据，数据总和第一次读取的一样， V1 : 100V2 : 100V3 : 200串行化（S）： 事务A在执行的时候，事务B会被锁住，等事务A执行完结后，事务B才能够继续执行 V1 : 100V2 : 100V3 : 200MVCC原理MVCC（Multi-Version Concurrency Control）多版本并发管制，是数据库管制并发拜访的一种伎俩。 特地要留神MVCC只在 读已提交(RC) 和 可反复度（RR） 这两种事务隔离级别下才无效是 数据库引擎（InnoDB） 层面实现的，用来解决读写抵触的伎俩（不必加锁），进步拜访性能MVCC是怎么实现的呢？它靠的就是版本链和一致性视图 ...

未创立索引 EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card=book.card LEFT JOIN phone ON book.card=phone.card; 增加索引 基于《MySQL 索引两表连贯查问优化案例》 中的准则，在两个右表中建设索引查看成果。 ALTER TABLE `book` ADD INDEX Y(`card`);ALTER TABLE `phone` ADD INDEX Z(`card`);

本文基于 gorm v2 版本 连贯数据库Go 外面也不必整什么单例了，间接用公有全局变量。 func Connect(cfg *DBConfig) { dsn := fmt.Sprintf( "%s?charset=utf8&parseTime=True&loc=Local", cfg.DSN, ) log.Debugf("db dsn: %s", dsn) var ormLogger logger.Interface if cfg.Debug { ormLogger = logger.Default.LogMode(logger.Info) } else { ormLogger = logger.Default } db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{ Logger: ormLogger, NamingStrategy: schema.NamingStrategy{ TablePrefix: "tb_", // 表名前缀，`User` 对应的表名是 `tb_users` }, }) if err != nil { log.Fatal(err) } globalDB = db log.Info("db connected success")}调用方应用 GetDB 从 globalDB 获取 gorm.DB 进行 CURD。WithContext 理论是调用 db.Session(&Session{Context: ctx})，每次创立新 Session，各 db 操作之间互不影响： ...

数据库 数据库是数据存储和治理的仓库数据库分类晚期：档次式数据库 网络型数据库当初：关系型数据库（底层以二维表的模式保留数据的库） 非关系型数据库（键值构造）蕴含关系一个MySQL服务器里蕴含多个数据库，一个数据库又蕴含多个数据表，一张表能够记录多条数据，每一行存储具体的数据SQL语局分类DML（Data Manipulation Language）数据操纵语言如：insert，delete，update，select（插入、删除、批改、检索）简称CRUD操新增Create、查问Retrieve、批改Update、删除DeleteØ DDL（Data Definition Language）数据库定义语言如：create table之类Ø DCL（Data Control Language）数据库管制语言如：grant、deny、revoke等，只有管理员才有相应的权限###数据库罕用操作 1，建库语言 create database 库名 default character set utf82,删除数据库 drop database if not exists 库名3，查看所有数据库 show databases4，删除表 drop table if exists 表名5，设计表 create table 表名（ .... ）； 6，查看表 desc 表名 7，插入数据 insert into 表名（字段名） values（数据） 8，查问表中数据 select * from 表名（* 可换成要查问的字段） 9，数据更新 Update 表名 set列= 值，列= 值 Update stu set score=score+10 where gender =’female’;给表中所 有女生加10分mysql不反对+= Update stu set score=83 where id=1; 10，删除表 Delete from 表名；删除表中所有记录 Delete from 表名 where id>1;删除id>1的数据Delete from 表名；删除表中所有记录 Delete from 表名 where id>1;删除id>1的数据11，查问表中总数据select count（*） from 表名12，表中数据排序select * from 表名 order by 形式字段束缚1,主键束缚自增id int primary key auto_increment2，惟一束缚，能够为nullusername varchar(50) unique not null3，非空束缚，不能null，能够反复password varchar(50) not null,4.外键束缚 ...