点击上方蓝字可以订阅哦

本文中的问题精选自上期【你问我答】——数据库专题中读者的提问。【你问我答】是由美团点评技术团队推出的线上问答服务，你在工作学习中遇到的各种技术问题，都可以通过我们微信公众号发问，我们5000+工程师会义务为你解答，欢迎大家踊跃提问。高质量、定义清晰的问题会优先获得解答。

Q1：能不能推荐几本关于SQL的书籍。谢谢！谢谢！

A：推荐图灵出的《SQL必知必会（第4版）》，这也是Amazon上最畅销的SQL图书的中文版，写得很明快，概念非常清楚。这本书用来学习关系型数据库也很不错，至少基本概念比大部头的教材说得清楚得多。

如果你英语好，这些网上的教程也不错：
https://www.sqlteaching.com/ 
http://www.w3schools.com/sql/default.asp 

Q2：我想问一下，这么些数据库，有关系的，比如MySQL，也有非关系的Redis、MongoDB这些引擎的底层实现、应用场景？

A：底层实现这个话题比较大，我主要说场景吧。

MySQL是关系型数据库，支持事务、支持索引、二级索引、MVCC，支持SQL、join，存储结构化数据、写入比较昂贵，并且从库同步单一线程，所以容易造成延迟，适合读多写少的OLTP业务。

Redis、MongoDB属于非关系型的NoSQL数据库，KV存储。Redis有丰富的数据结构，Remote Dictionary Server，支持Hash查找，可以自己构造二级索引，由于它主要定位于内存查询，所以适合对响应时间要求极高、数据规模可以预见、热点数据比较集中、不存在冲突的场景，与Lua结合实现秒杀，但不适合大批量导入数据、数据量较大的业务。MongoDB支持单文档事务，可自动故障切换，比较容易扩展分片，适合数据量大场景。

Q3：美团点评如何优化数据库才能保持高性能呢？ SQL优化方式是什么呢？

A：放两篇之前的技术博客

索引原理以及慢查询优化： https://tech.meituan.com/mysql-index.html

SQL优化工具：https://tech.meituan.com/sqladvisor_pr.html

优先基于开源box/Anemometer有一套慢查询系统，然后每个业务线会定期有慢查询报表，同时我也有一套开源SQL Advisor工具进行优化。

Q4：能不能简单介绍下时序数据库的应用场景，和其它NoSQL数据库有啥区别？

A：时序数据是基于时间的一系列数据，传统数据库仅仅记录了数据的当前值（虽然会有快照读），时序数据库则记录了所有的历史数据，它可以用于趋势预测，根据历史进行大数据分析，实现预测等场景。它和NoSQL其实是两个维度的产品，它比较适合LSM tree数据结构，该数据结构普遍用于NoSQL中。

Q5：TiDB对标的是Spanner，它们对于像select from order by key limit offset 100这样的实现思路是怎样的？因为，它们具有sharding , 如果这个key不是分区建？那么下推，转换成top offset+100然后merge sort？是这样实现的吗？或者还有什麽黑科技？

A：这个问题，我的理解和你基本一致。如果该key无索引的情况下，最差的方式是全部下推到各个节点进行查询，然后merge；如果有索引的话，有可能根据会根据该节点该索引最大最小值先进行判断，然后进行提前过滤掉，不过这个我不是很确定，我后面和TiDB的同学沟通下再答复。

Q6：数据库以及SQL优化的方案有哪些？

A：分几个层面:

1. 系统层面：纵向扩展数据库服务器配置，简单粗暴。

2. 数据库服务端层面：配置参数调优等，比如调整数据库连接缓冲区大小。

3. 架构层面：如果当前是单实例架构，或多实例垂直架构，根据应用特点，可以考虑升级架构，如常见的主从架构等。

4. 库表层面：可以考虑分库分表。表的拆分，根据业务特点，可考虑水平拆分或垂直拆分。

5. SQL层面：这个最常见有效，对开发来讲，经常用到。具体到设计表的设计，索引的设计是否合理；对于DML语句，使用命令explain查看执行计划，根据执行计划的结果进行分析调优。

Q7：请问MySQL分表和分区各自的优缺点是什么？分别适用于什么场景，谢谢～

A：先说分区表，其实MySQL的分区表适用的场景比较有限和苛刻，首先要最大程度满足分区裁剪，即查询条件需要有分区字段，否则全表扫描性能就不可控，即时索引扫描，因为MySQL的分区表索引都是local，没有全局索引。分区表在数据清理，归档上会很友好，所以我们这边主要用于诸如log类的有很好分区维度（时间），并且历史数据是静态数据，或者有定期归档删除需求的场景。分表的目的是避免表太大导致的索引高度变大、表查询性能下降，为了性能可以损失一些易用性的场景，比如SQL需要更简单，聚合操作需要在业务层实现。

分库分表的实践之前我们也发表过两篇文章，可以参考：

大众点评订单系统分库分表实践

MTDDL——美团点评分布式数据访问层中间件

Q8：水平拆分，后期“表结构一致性”如何验证？然后就是合并查询是应用层实现的吗？

A：表结构一致这个验证其实在美团点评的需求比较低，因为我们在权限、流程会避免只在某一个节点进行DDL，另外check起来的方案也比较容易，比如直接在多节点对比schema_info.tables就可以。合并查询我们这边会Zebra（JDBC连接池的proxy）进行处理，不过有一定局限性。

Q9：现在业界MySQL Binlog同步使用Paxos的有开源的实现吗？MySQL Proxy前端负载均衡路由/代理能够灵活地支持prepare语句或者复杂的join多表查询吗？

A：Binlog同步Paxos实现，没太明白这个问题，MySQL官方的MGR就是Paxos实现的。

美团点评的Proxy就是Atlas，如果是非分库分表的话，支持表多表join，如果是分库分表的话，限制就很多了，如下：

• 分库分表限制

1. 分库分表列仅支持整形（int和int64）。

2. 仅支持select、insert、replace、delete和update。

3. Insert操作，如果没有显式的指定列名，则会按照value list的第一个值来计算。比如Insert values（c1,c2,c3），则按照c1来计算分库分表。

4. 不支持 INSERT INTO tbl SET col = xxx，INSERT INTO tbl SELECT * FROM xxx 形式。

5. update修改分库分表字段的值时，只会修改值，不会根据修改后的值再对数据进行迁移。

6. 不支持跨库查询的Limit、Sort、Group by和Union操作。目前Atlas只是简单合并转发后台的结果集。

7. 不支持分库分表的表中含有自增列。

8. 不支持join语句中含有多个分表，因为Atlas无法同时替换语句中的多张表。如果含有多个分库表，则分库规则必须一致，否则可能结果错误。

9. 不支持分表名出现在表达式中，比如select shard_table.col + 1 from shard_table where shard_table.shard_col = xxx，因为其中的表达式不支持表名替换；分库仍然支持。

10. 不支持targetlist中有函数。

11. 不支持 sharding 表出现在 FROM 语句的子查询中，例如 SELECT * FROM (SELECT * FROM tbl_sharding) as a；(目前的 rewrite 机制不支持子查询)。

12. 不支持SQL_CALC_FOUND_ROWS语句。

后台DB连接池带来的限制

不支持cursor、prepare等功能。

Q10：什么是前置库，该如何配置呢？

A：在数据库范畴里，貌似并没有前置库这个概念。但我猜测是不是大数据里数据来源库？如果是MySQL的话，我们会普遍使用对Binlog进行解析，这样对源库的影响很小，并且可以支持增量同步，解析的工具开源的很多，比如在美团点评就有三个canal、databus、pumer，地址自己搜一下吧。（有可能答非所问）

（小编特别提醒：提问的时候，问题一定要说清楚背景，不然我们专家也难为无米之炊哦）

关于数据库，如果你有其它方面的疑问，可以扫下面的二维码加入我们的“数据库”微信群进行提问和讨论哦~赶快拿出手机扫一下吧~