书由：

网上一些对书的点评，说是一本实际运营故障处理的维护手册。许多只有大公司才能碰到的案例，里面有不少内容如果不了解阿里内部细节，还是不容易看懂的。

这本书的给的介绍与定义是，负责阿里大平台生产稳定性的技术小二的代表，把他们这些年在基础架构、中间件、数据库、业务研发、运行管理等大型互联网

平台的稳定性建设中积累的宝贵实战经验，用平实无华的语言娓娓道来。这些技术沉淀既是对过往典型故障的深度分析，也是跟同行们切磋交流的宝贵知识财富。

dns线路机制

作为维护人员，在处理域名相关的变更时更需要多加注意。比如:域名是由权威DNS和各地运营商或第三方机构的缓存 DNS等，在转移权威DNS服务提供商要在旧的DNS提供商中保留正确的解析至少48小时;在自己搭建DNS时，多加测试，注意兼容性;在配置多线路的智能解析(不同来源，指向不同的地址，

即让DNS根据来源的不同而返回不同的值)时，要注意每个线路均能正常解析。出现问题时，可借助dig/nslookup等域名诊断工具以及域名的whois信息来诊断。

禁用select*

Select*带来的便利是对于字段较多的情况下，可以少写字段，不会出现在业务代码中遗漏字段的情况。但大家应该也了解， select*会查询出数据库的所有字段，如果某个字段很大，可能对

性能有影响，一般建议按需使用字段。如果认为select*的弊端仅

仅是以上这些，那就大错特错了。为什么DBA强烈禁止使用 select*，阿里巴巴集团开发规约也把其作为禁止使用的条例，肯

定是有原因的。

本节场景举例，某项目发布阶段，因为业务需要新增表字段，从sql的代码逻辑来看，使用了select*,新增字段应该是兼容的，但在做线上数据库ddl操作之后，立即出现了日志错误数飙升报警，说明数据库新增字段并不兼容。

分析出现错误的原因是由于分库分表，共N个库（N大于4），数据库表变更的时候，是分库分批执行的。N个库变更完成，历时M分钟（时间长短取决于分库分表数据等因素）。tddl在执行的时候，碰到Select*, 会从数据库表中解析出对应的全部字段，取第一个库的第一个一进行解析，解析之后会缓存结果。替换*，然后再把解析后的sql语句提交到目标数据库执行。在第一个库变更之后，tddl拿到最新的字段列表，后续一段时间内的查询，都直接用带有新增字段的sql语句提交到数据库执行；由于有部分数据库还没执行变更，没有新的字段，导致数据库执行出错，无法查询数据。

本案例是因为不了解tddl中间层对select*的解析逻辑，导致数据库变更时出现不兼容问题，但使用select*的弊端不限于此，比如select*查询非必需字段，会造成资源浪费甚至影响服务器性能；增加sql的解析成本，表结构变更可能会引起字段映射问题；不会使用覆盖索引，不利于查询的性能优化等。