数据库学习地图

1不知道该怎么说，我在数据库上并不擅长，虽然在数据库部门待过，但是做的是NoSQL的东西。我想你指的应该是常规的关系型数据库吧，我说点自己的经验给你参考吧。这个是作为开发人员的角度，不是DBA的角度。
2首先是数据库的原理，这个大学课程肯定有讲到，不过不是很深入，一般关系理论和关系代数也会讲到，接着是三大范式以及后来的BC范式等等，这个一般是重点要掌握的，对实际项目数据库的设计有重要意义。其他的概念也有重要的，不过过了这么久我觉得在工作中作为一般的非专门的数据库工作者来说，这个我自己用到的最多。然后是具体的SQL语言，一般会结合一个商业或者开源数据库学习，这个也是很重要的，要比较系统的学习和掌握，
3这里书上一般会讲到SQL的优化，即实现某种查询需求的最佳实践，有些从关系代数的运算上就能直观理解，有些要结合具体的数据库存储引擎从系统层面去理解。
4这些东西也是工作中要注意的，一般要结合场景和业务需求去具体分析，就不举例子了
5这时候涉及到数据库的编程语言接口层面，比如最容易想到的JDBC
当然，这是Java自己建立的抽象层
6就不严格区分概念了，总之，要开始一个实践，从显示世界的角度出发，把数据存储需求映射到二维的关系型数据表上去，这时候衡量和指导设计的就是之前提到的各种范式
7这个过程反复进行，完成后就是根据具体的需求去CRUD
可能在大学的课程，截止这一步就结束了，剩下的要自己继续走。
剩下的我简单说下，如果你走到这一步了，可以群里问，我可以继续说后续的，如果我拿不准，可以帮你去问问更专业的同学。
8接下来可以去了解一个数据库的内部实现，比如很容易找到资料的MySQL，开始研究某种存储引擎，比如InnoDb，这时候很多数据结构和算法乃至操作系统的知识就来了，需要你慢慢理解。
9然后当你掌握了一两个存储引擎的实现后，你会发现一样的SQL在两个存储引擎上效率并不相同，因为某些具体的实现所以有差异，那么这将指导你在编程上刻意针对数据库优化，当然，不是很建议，因为一旦更换数据库或者存储引擎，可能会成为意想不到的瓶颈，但是我们遇到的现实问题是，业务上已经被逼的要根据底层实现做针对性优化了。
10有点跑偏了，稍微退回去一点说。当你做了一个小东西的时候，你可能用到了几张表，用了一点点CRUD的语句，但是像视图，存储过程，触发器等你并没有遇到，事务这种略高级的特性离课程设计的距离更远
11这时候，在学校里的话，你就要去做一个距离真实场景更接近的东西，比如模拟一个电商网站，比如某宝，某猫，某东，重点在数据库上，不用做界面，直接命令行模拟查询数据库，显示就行，这时候关于数据库的设计要求更高，你可以很容易的写出来并发请求的任务去压测，看看你的模型瓶颈在哪里，可以随机甚至直接用爬虫去拉某东的数据存下来，然后根据你的性能瓶颈去做优化，也许是调整表，也许是加索引，也许是拆表。商品，库存，用户，交易，任何一个部分都可能出问题，你会发现三大范式有时候不能照搬，不见得第三范式在实际中真就那么强。
12甚至你会可以增加数据表的冗余字段来避免跨表查询
这时候事务等特性避免不了了，因为有交易
单点达到瓶颈后，就要考虑分开了，从简单的主备读写分离到多机多活，有一个看似牛逼的东西出现了，分布式数据库
单点达到瓶颈后，就要考虑分开了，从简单的主备读写分离到多机多活，有一个看似牛逼的东西出现了，分布式数据库
其实并不难，数据存储当单点到了瓶颈怎么办？拆呗
13一般的分布式存储系统的思路就是分片路由加多份容灾
具体到数据库，最简单的思路是分库分表，有垂直和水平两种，各有优势和困难
这里不展开，自己想优缺点
14一旦水平分开，SQL怎么处理，跨表跨库的查询变成了跨机器的查询，这时候怎么办？事务怎么办，分布式事务又是一个问题。一个新的领域又向你展开。
淘宝有个开源的TDDL，可以去玩玩。
外号叫 头都大了
后面的不说了吧，可能暂时太远了
淘宝有个开源的TDDL，可以去玩玩。
外号叫 头都大了
后面的不说了吧，可能暂时太远了
我大概理了一条线，但是整个数据库的知识是一个毛线球，所以希望能打开你的思路而不是把路变成一条。那样我就有罪了。
我大概理了一条线，但是整个数据库的知识是一个毛线球，所以希望能打开你的思路而不是把路变成一条。那样我就有罪了。