课程亮点
- 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；
- 慕课专栏版权归本平台所有，任何机构、媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布 / 发表，违者将依法追究责任。
骑着猪找未来
问题一：从文中的信息来看，count(n)或count(*)是走索引的，猜测sum()是因为不走索引导致的 问题二：书写顺序为select、from、where、group by、 order by、having
讲师回答 / 张勤一
骑猪你好，确实是这样的，顺序是对的
阿斯拉菲
问题1 case when 经常统计、纵表转横表的时候用过，ifnull, if 个人相对用的少 问题2 这个亲身体会，mysql 5.x版本默认大小写不敏感，mysql 8 默认大小写敏感，修改的话必须是数据库初始化之前修改，之后更改是无效的
讲师回答 / 张勤一
是的，这些判断语句在部分情况下是比较好用的，但是，如果不这样写，其实在代码中判断，效率也是非常高的，不一定非要这样用。关于大小写敏感的问题，我的个人习惯是精确查找，而不是依赖于数据库系统的特性。
沁尘
问：将时间转换为时间戳，并使用 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，那么，后期的迁移将会是很大的工作量。