关系型数据库
仍然是非常重要的一种技术。作为一个后端架构师，必须会。
- http://blog.csdn.net/defonds/article/details/52241432
- https://book.douban.com/subject/26419771/ (书籍推荐）
- http://blog.jobbole.com/87450/ (运维角度)
- http://www.searchdatabase.com.cn/showcontent_89267.htm
- http://www.oracle.com/technetwork/cn/community/developer-day/6-db-optimization-360099-zhs.pdf (更全面和综合的分析）
- https://my.oschina.net/junn/blog/113153 (50种手段）
- http://www.cnblogs.com/yunfeifei/p/3850440.html (简单总结，术的总结）
你不能是学习DBA要学的所有关于DB的内容，你要学习的是，开发者或者架构师更应该理解的部分，更专业部分需要专门的DBA.
面向开发者的，DB知识。
道：
- 表的组织结构符合业务需求
- 索引的结构符合业务需求
- 查询语句尽量利用索引，尽量保持查询计划的稳定，不因，表的一点改动，而改变巨大，导致性能大幅下降
- 写避免占用过多的资源，用尽量小的锁。
- 对于不同的应用场景采用不同的措施，OLTP写, OLAP静态数据，可以不过多考虑写。
- The fewer indexes a table has, the better the
insert,deleteandupdateperformance.
业务场景
- 电商系统
- 交易系统
- 金融系统
- 电信系统
- 计费系统
NoSQL角度看关系型数据库
本人观点，互联网技术架构的发展，就是围绕传统数据库在不足，发展起来的，查询慢，上Cache；写入慢，是不是可以换成其他类型的存储格式，抗不住高并发，用消息队列，削峰限流；大数据，也是围绕他的不足，数据库存不了大的数据，做集群麻烦（猜测），然后，Google直接从文件系统开始改造，造出了GFS存数据，造出列BigTable，造出了MapReduce在上面计算。
基本技能
对于开发者，基本能力是能够根据场景设计的表结构，查询语句，更新语句更快地响应应用程序的请求
表的设计
- http://blog.jobbole.com/93953/
- http://www.vertabelo.com/blog/technical-articles/7-common-database-design-errors
如何写出高效的SQL?
范围查询，
如何设计表结构和索引，以加快读取方式？
什么样的查询会用到索引？
- orderby 排序会用到索引吗？在期望返回的数据较少时，可以。如果返回的数据占表的大部分，使用索引反而会拖慢速度，因为你不仅要访问数据块，你还要随机地访问那些索引块，还不如把大部分数据加载进来，进行排序。
https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html
- where v in (1,2,3)会用到索引吗？会。
http://use-the-index-luke.com/sql/where-clause
- 复合索引的内涵，创建和使用注意事项。相对于，单列索引
http://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys
术： 能用单列索引达到复合索引同样的性能，就避免使用复合索引，因为索引越多越复杂，就会对表的写操作带来更到的额外成本。
组合索引 OK
聚集索引 OK
性能优化的思路和手段
单表优化 -> 分表或者分区。
单表优化： 表设计，索引设计，查询设计。
磁盘 -> 文件系统 -> 操作系统(CPU,Memory) -> 数据库本身（一些相关配置）
架构层面：分库，主备，缓存服务器（Memcached)
手头上的书
- PostgreSQL 9.0 性能调教
- 数据库系统设计
简单有效的术
术不可离道，所以不要只是硬背术，也要知道术的本源，才能融会贯通，从更高层次，系统把握。
问题集
如何判断索引会不会被用到？
这是解决查询性能低下的一个基本思路，这个查询慢，是不是加索引，可以提高性能。换句话说，就是索引在什么情况下才会对查询带来正面影响？另一方面，如何写查询语句，才能使用到已建索引，提高性能？针对不同的场景，改如何建立索引，建立什么类型的索引？聚集索引和非聚集索引的区别？
例子：
- Where中使用null, 会使数据库引擎放弃使用索引。(http://www.cnblogs.com/yunfeifei/p/3850440.html\
索引的知识体系
位图索引 ：http://www.cnblogs.com/LBSer/p/3322630.html Postgres, MySQL没有位图索引，Oracle有位图索引。
索引的道:
数据有序关系，数据有相等关系， 人类就是要在这些关系所组成的结构中，找期望的数据。如果数据本身是易于计算两者之间的关系，那么普通的索引，就可以满足你的需求，无论数据是什么类型。只要你能给索引系统给出这个数据类型的高效的序关系计算算法。因为日期类型很容易就可以表示成固定的几个字节，所以比较起来成本也很低，没什么特别，比较 成是O(1)。但是，字符串不一样，是变长的，字符串比较的复杂度的下届至少是O(m+n)，所以说，字符串的索引无论是建立还是搜索都很低效。所以出现了，解决这个小问题的术：前缀索引。
索引的实践，上手
- https://yq.aliyun.com/articles/7444 (字符串的正则与模糊查询）
create index idx_tb_info on tb(info text_pattern_ops);
如何检索字符串也是数据库的一个重要的方面？
基于数据的全文搜索，肯定弱于专业的搜索引擎，但是依据你的应用场景。你的应用场景不需要一些全文搜索的高级特性，基于数据的全文搜索，我认为，是可行的方案。
关系数据库两个基础的核心问题：
- 如何设计表？
- 如何查询？查询优化，索引，如何写出高效的SQL? 连接的类型？
- 如何做修改操作？事务ACID，隔离级别? 还不是特别清楚，锁，乐观锁，悲观锁，触发器
- 其他：存储过程
事务隔离级别
- http://www.jianshu.com/p/4e3edbedb9a8 五星资料，简洁易懂
===========================================================================================
隔离级别 脏读（Dirty Read） 不可重复读（NonRepeatable Read） 幻读（Phantom Read）
===========================================================================================
未提交读（Read uncommitted） 可能 可能 可能
已提交读（Read committed） 不可能 可能 可能
可重复读（Repeatable read） 不可能 不可能 可能
可串行化（Serializable ） 不可能 不可能 不可能
===========================================================================================