实战派 MySQL 高阶应用指南-原创专栏-慕课网

实战派 MySQL 高阶应用指南

打包 MySQL 常用高级技巧特性

张勤一 · BAT 高级研发工程师

共计35节 · 已更新35节

597人已订阅

课程亮点

MySQL 热门高级知识点学习
企业级研发案例实战演练
应用方案设计的思维突破
实际项目调优的干货技巧
技能提升 / 中高级面试利器

课程简介

数据库，是一个程序员的必备技能。而 MySQL 作为时下最流行的关系型数据库管理系统，甚至在可以预见的未来 MySQL 都将是最流行的关系型数据库管理系统。

研发 / 测试 / 前端 / 客户端… 无论你是哪个岗位，一定不会对 MySQL 陌生，且大概率使用过 INSERT、DELETE、UPDATE、SELECT 等命令来完成对数据记录的增删改查。

但是，你肯定也听同学、同事抱怨过 “MySQL 太复杂了”“太难了” 之类的话。这通常是在使用 MySQL 的过程中，遇到了错误或者是性能问题。如果缺乏有效的学习，你的 MySQL 技能提升将会遭遇瓶颈，陷入一段时间内原地打转的尴尬境地。而且 MySQL 的复杂性也很容易让人面临刚解决一个难题，下一个未知的难题又突然出现的状况。

为此，本专栏将常见、常用的 MySQL 技巧进行集合，并通过小案例知识点和企业级应用案例实战的方式，带领追求进步的你掌握 MySQL 的高级技能，提升职场竞争力。

课程模块：
本专栏由浅入深，从 MySQL 的基础知识点开始讲起，逐步过渡到进阶知识、高级特性与应用设计技巧等等。除了基础理论之外，专栏中包含有大量的真实操作案例，并在最后设置了两个数据库应用系统项目实战，达到学以致用的目的。专栏一共包含 7 个模块：

第一，MySQL 基础
主要对 MySQL 的基础应用与基本使用建议进行讲解，但并不涉及例如 MySQL 的安装、基本的增删改查语法。主要是讲解我们平时常见但又常常忽略的功能点，例如：聚合与分组聚合、用户与权限、数据备份与恢复等；

第二，MySQL 进阶
讲解 MySQL 的进阶知识点，即我们平时常用，但是难度较高、不易理解的知识点，熟练的掌握这些知识点，能够在使用上达到事半功倍的效果。内容涉及：事务隔离级别、锁对并发的影响、高级查询、死锁等等；

第三， MySQL 高级特性
讲解常见、常用的 MySQL 高级特性。毫无疑问，MySQL 提供的高级特性主要用于两个方面，一方面是使用上的优化技巧、另一方面是特殊的使用场景。想要高效的使用 MySQL，对于高级特性的掌握也是必备的技能；第四，应用设计技巧与调优
针对两个方向进行讲解，一是应用的方案设计、二是实际问题的建议与调优。本章的内容不仅仅是理论层面的分析，更是结合了作者多年的工作经验与实际问题的处理办法；

第五， MySQL 的实现原理
为了做到知其然也知其所以然，这一模块对实现原理进行讲解。首先从高层次理清 MySQL 系统的逻辑架构、再去分析 SQL 解析器、查询优化器的实现原理，最后讲解 InnoDB 存储引擎以及事务的实现原理；

第六，实践应用
理论结合实践是最好的学习方式。这一模块里我会对电商系统、慕课网的数据表进行设计，其中会应用到我在课程中所讲解的 Schema 设计规范、性能优化技巧等等知识点；

第七，总结与思考
总结部分将会对本专栏的知识点做出总结，指出重点内容；展望部分对专栏以外的知识点做介绍，提供继续学习方向的指导；思考部分则留出开放性思考问题，以便讨论交流。

查看全部

专栏目录

精选留言

更多精彩留言

适合人群

有 MySQL 基础的同学
想要学习更加核心 MySQL 知识的同学
为工作技术进阶做准备的同学

购买须知

本专栏为图文形式内容服务，共计 35 小节，上线时间为 2020 年 3 月 10 日，预计 2020 年 6 月 10 日更新完成；
本专栏更新时间为每周 1，3，5 更新 1 篇（法定节假日顺延），形式为图文；
订阅成功后，用户即可通过慕课网 PC 端、App 端、WAP 端享有永久阅读的权限；
慕课专栏为虚拟内容服务，订阅成功后概不退款；
在专栏阅读过程中，如有任何问题，请邮件联系 kf@imooc.com；
慕课专栏版权归本平台所有，任何机构、媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布 / 发表，违者将依法追究责任。

0 / 0

登录后可任选 0 个小节免费阅读

骑着猪找未来

问题一：从文中的信息来看，count(n)或count(*)是走索引的，猜测sum()是因为不走索引导致的问题二：书写顺序为select、from、where、group by、 order by、having

讲师回复：骑猪你好，确实是这样的，顺序是对的

2020-03-16

阿斯拉菲

问题1 case when 经常统计、纵表转横表的时候用过，ifnull, if 个人相对用的少问题2 这个亲身体会，mysql 5.x版本默认大小写不敏感，mysql 8 默认大小写敏感，修改的话必须是数据库初始化之前修改，之后更改是无效的

讲师回复：是的，这些判断语句在部分情况下是比较好用的，但是，如果不这样写，其实在代码中判断，效率也是非常高的，不一定非要这样用。关于大小写敏感的问题，我的个人习惯是精确查找，而不是依赖于数据库系统的特性。

2020-03-13

沁尘

问：将时间转换为时间戳，并使用 int 或者 bigint 类型去存储，你觉得这样可行吗？答：看正文的时候正好奇为啥没提到存储int/bigint时间戳，用int/bigint和datetime存储在不同项目都使用过，感受就是int/bigint计算上很方便。特别是当前端项目对于时间展示有不同的格式需求的时候，数据库中存储的是int/bigint（或者vo层转换）直接返回给前端，前端可以更方便的定制格式而不用先把datetime转成时间戳。但是如果没这方面的需求，那直接存储datetime就是最方便的，可以减少转换的次数。所以个人觉得，从存储角度上来说，如果没有格式定制的需求，直接存储datetime最省事。问：大多数时候，我们会选择将主键设置为 bigint 数据类型，你知道这是为什么吗？答：不知道

讲师回复：沁尘你好：第一个问题，是否可以考虑将时间存储为整型？这是完全可以的，正如你所说，时间是整型的话，前端可以方便的进行转换，而且不用考虑精度的问题，且这种转换带来的性能损耗几乎是可以忽略不计的。当然，如果仅仅是 java 系统之间使用的话，使用 datetime 存储是最方便的，序列化和反序列化都只需要一个注解就可以完成。第二个问题，为什么考虑将主键设置为 binint 类型？这里的主要思想就是为了将来的扩展，因为 int 类型的最大表示范围大约是 20 亿，这对于 99% 的项目都基本足够用了。但是，如果考虑到将来业务发展的比较迅速，就需要使用 bigint 了。如果一开始没有使用 bigint，而是使用 int，那么，后期的迁移将会是很大的工作量。

2020-03-11

街边七号

1.为什么执行flush logs?猜测可能mysql执行操作后不会立即将操作信息记录在binlog,而是停留在内存中由mysql服务器在合适的时机进行异步刷盘，执行flush logs来确保最新的数据库操作可能记录在binlog中，来防止数据恢复都是 2.不知道

讲师回复：第一个问题说的是对的，先保存在内存中，起到缓冲的作用；第二个问题的话，其实就是指定起始位置和起始时间

2020-03-18

沁尘

问：如果你的表没有定义主键，你知道 MySQL 会怎么做吗？答：Innodb表中在没有默认主键的情况下会生成一个6byte空间的自动增长主键我需要创建一个学校库，存储教师、学生、院系等信息，你觉得叫做 school 好吗？为什么？答：个人觉得业务初期可能没问题。但是学生表后期会膨胀，很有可能独立成一个库或者为这个表做备份库，如果这个学校库起名叫school，那学生库或者学生表的备份库起名字的时候选择会比较苦难，不大好起一个简要达意的名字，不知道这么考虑对不对。问：我编写的 SQL 语句需要做多表的 join 操作，应该给哪些列建索引呢？答：where子句中的字段

讲师回复：沁尘你好：第一个问题，如果你的表没有定义主键，那么 MySQL 首先判断表中是否有非空的唯一索引，如果有，则该列即为主键；如果不符合上述条件，InnoDB存储引擎自动创建一个6字节大小的指针。第二个问题，直接命名为 school 并不好，最好是加上一些前缀（比如地域之类的），主要目的是方便未来的扩展，比如加入其它的 school，不会同名。第三个问题，join 操作的话，where 条件和 join 的列最好都加上索引，但是，此时需要考虑索引的个数不要过多（一般一张表的索引个数不超过5个）。

2020-03-11

街边七号

1. 用mybatis动态sql作批量录入 2. 可以考虑, 但此时sql耗时应基本集中在数据录入和更新索引的操作上, 性能受限于磁盘的因素应该比较大, 上多线程不如换ssd. 3. 单条录入需要mysql服务器每次都检查语法编译sql语句耗时较长, 批量和Load data可以省去很多这些事件, 但同样的批量录入这种形式增大了单条sql的大小及设置的package参数。此时单条sql从客户端发送到mysql服务器的时候会比较长,占用带宽。

2020-05-11

街边七号

1. a.自增主键. b.尽量保证字段小一些. c.适当的冗余存储. d. 尽量让列值非空. 2. where子句字段类型和操作值的类型不一致如varchar类型的列`year`判断时使用where year = '2020'; like模糊前缀匹配; 对于聚簇索引条件丢失前缀匹配; where中使用SQL函数; 查询不使用索引列. 3.

2020-05-11

街边七号

1. 环形哈希空间，添加节点后很多数据不需要移动。 2. 垂直拆分实现简单，而且水平拆分可能会导致where查询实现困难。 3. id决定了数据记录存放的库和表，可以定位到数据的存放位置。 4. 使用定时任务做同步，但是业务中直接查询结果由于定时任务可能延时可能变得不可信，需要自行校验 5.没想到什么好办法，就是自己维护一个userid和这些信息数据映射关系，并以此来找到userId再进行查询

2020-05-09

无心铁憨憨

一哥，有个问题没想明白，在事物隔离级别为可重复读的情况下，事物A第一次读取的数据为1800，然后事物B修改为2000,事物A再次读取还是1800，因为事物B没有进行提交，但是当事物B提交之后再读取还是1800，那2000去哪里了，是否要等事物A执行完毕之后，再次查询，才会读到最新的2000？还是说需要在一个新的会话中才能读取到最新的数据？

2020-04-10

想好名字再改

老师，假设我要查询每个用户能够接受的最大的预算的广告信息该怎么写我目前的写法 SELECT user_id,MAX(budget) FROM ad_unit WHERE unit_status = 0 GROUP BY user_id 我还想看到这条广告的详细信息

讲师回复：最好的做法不是写一条 SQL 语句，而是在代码中经过两次查询，再去拼接对应的信息

2020-04-05

街边七号

1. 三阶 2. 如若联合索引使用了两个字段，应该是类似将两个字段进行封装变为一个node整体，然后按照字段顺序进行排序，如(name, salary)，索引会将{name, salary}视为一个整体，数据优先按照name进行排序，name相同时按照salary排序，一直到叶子节点。 3. 前缀索引可能会适合一些字段内容较长，但存在数据头部的一段短数据区分度可能较高的数据。 4. 建立在频繁作为查询条件，且数据区分度较高的列以及表间关联列。对于文章中提到的覆盖索引，如果存在某个列值频繁使用的话，可能为了避免查询回表，也可以考虑对其建立索引。建索引就是为了查询快。

讲师回复：感谢你的回复，答案是准确的

2020-04-05

街边七号

1.视图使用场景。目前使用经历，当数据分布在多个表中,且表之间通过id进行关联，无法直观的在可视化工具中看到数据之间的关系(直接看到的都是其他表的id)，此时会考虑建立视图，方便查看。 2.视图的数据表区别和联系，目前知道的就是视图并不会存储数据，个人理解视图就像一个保存好的sql语句，可以随时执行；视图数据来自数据表；视图理论上不建议使用增删改,就如同它的名字,只用作查看即可。 3.- 4.删除视图后,母表不会受到影响，受影响的是依赖该视图的其他视图，此时其他视图会阻止删除该视图。

2020-05-08

林可98

老师，我找到答案了。首先CHAR(M)、VARCHAR(M)、TEXT(M)中M的都是代表最大存储字符的个数。区别在于，VARCHAR最多存65535个字节，而TEXT最多能存储65535个字符。所以理论上，TEXT能存的字符是VARCHAR的3倍。比如，如果都是中文，utf8编码下VARCHAR最多只能存入65535/3=21844个汉字，此时M最大值只能填21844。但TEXT可以实打实存入65535个字符。TEXT最大容量是65535*3个字节？ help命令真的很好用，谢谢老师

2020-05-11

街边七号

1. 不清楚，不过观察日志发现在`UPDATE,DELETE,INSERT`这种事件中日志记录的是table_id，而紧挨着的上面一条table_map事件就记录了操作的数据库.表名和tableid的映射，但是不明白为什么不直接记录，而要分开记录为两个事件。 2.在information_schema.innodb_tables中找到了table_id的列,但是值和binlog中记录的并不一致 3.

2020-05-10

小白技术

MySQL的权限数据表设计真的很不错

讲师回复：对的，而且你可以从这里想一想，如果你的业务系统中需要权限系统，是不是可以模仿着 MySQL 来实现

2020-03-27

骑着猪找未来

这一节加深了对缓存和以空间换时间的体会，果然知识都是相通的。

讲师回复：哈哈哈，对的，多去思考，然后最好是扩展到自己平时的业务中去

2020-03-18

— 造烛求明，读书求理 —

￥68.00

立即购买