ORM规约变更经典案例---mysql军规

　　先介绍一下《MySQL数据库开发的三十六条军规》，这里只介绍核心的，具体内容大家可以自行百度，这是从底层开发人员到管理者必须知道规范。出自58赶集。

写在前面的话：
　　总是在灾难发生后，才想起容灾的主要性；
　　总是在吃过亏后，才记得有人提醒过。
核心军规：
      不在数据库做计算，CPU计算务必移至业务层；
      控制单表数据量，单表记录控制在千万级；
      控制列数量，字段数控制在20以内；
      平衡范式与冗余，为提高效率可以牺牲范式设计，冗余数据；
      拒绝3B(big)，大SQL、大数据、大批量

　　介绍两个例子。这个适合用STAR法则。STAR法则是情境(situation)、任务(task)、行动(action)、结论(result)四项的缩写。STAR法则是一种常常被面试官使用的工具。一般常说的开放性的问题，就是设立一个场景怎样解决问题基本用的是这种工具。

案例1：

以下是我们组发生的一个真实例子，具体操作和调研是由我两个同事实施的。

情境：

　　核心交易目前在进行代码重构，数据模型的重构是其中重要的一个环节。一天我们同事在进行DDL(Data Defination Lauguage)的变更，由于两个字段比较相近，但是其中一个是原有字段不可为空，另外一个是新增字段，允许为空，结果空字段被赋值给了非空字段，DDL执行导致大量异常。DDL变更回滚后日志恢复正常。

任务：

　　从java程序到连接mysql数据库用到了atlas、mybatis、数据库驱动到达mysql数据。而字段的映射是mybatis这样的ORM(Object Ralational Mapping)框架来处理的，我们的任务就是分析mybatis的源码和配置，找到问题的根源和以后要注意的事项。　

行动：

　　下载mybatis源码进行调试、分析。当前生产环境中，Mybatis版本是3.2.8.

　　在使用mybatis时，有时可以不定义resultMap，直接在<select>语句上指定resultType。此时涉及到Mybatis的结果集自动映射。Mybatis的自动映射。Mybatis的自动映射默认开启。分析源码理解mybatis结果自动映射原理：

　　1. mybatis自动映射预处理流程：

　　2.自动映射流程(applyAutomaticMappings方法)

　  就是说applyAutomaticMappings要用到两个配置参数：mapUnderscoreToCamelCase和callSettersOnNulls。

　　mapUnderscoreToCamelCase:是否开启驼峰命名。开启后会对大小写、下划线均不敏感。

callSettersOnNulls:是否在该字段值为null时将结果同时反射set赋值方法进行赋值。

　　3. 自动驼峰命名规则测试实验

实体属性	字段名	是否自动驼峰命名	是否可以赋值
deviceId	device_id	true	赋值给deviceId
deviceId	device_id	false	没有赋值给deviceId
traceno traceNo	traceno	true	赋值给traceNo
traceno traceNo	trace_no	false	都没有进行赋值
traceno traceNo	trace_no	true	赋值给traceNo

 

结论：

　　在映射时会先把没有在resultMap中定义字段映射的字段按照名称相同的方式自动映射到返回类型的对应属性上。自动映射会忽略下划线和大小写。

　　Mybatis settings配置项说明应该仔细研读。

　　字段定义各个字段之间的区分要尽可能的大，严禁使用只有大小写和下划线不同的两个字段。

　　我们现在在做分享会和读书会，我的想法是这些学习活动要尽量贴近项目，做有深度的学习。代码是随便找个人培训一下就可以写的，但是写出代码的效率和可维护性等代码质量的要求决定了大公司对初级程序员要求的门槛。而对所有技术研究的深度决定了突发问题的解决能力，对后续的建设提出的指导和建议。

案例2：

　　《逆流而上》里介绍的一个案例。

情境：

　　在某次项目发布阶段（数据库使用了分库分表），因为业务需要新增表字段，从SQL的代码逻辑来看，使用了select *，新增字段应该是兼容的，但在做线上数据库DDL操作后，立即出现了日志错误数飙升报警。当回滚还未执行，日志错误就已经自动恢复。

任务：

　　从问题的现象来看，这个问题只有在变更过程中才出现，不太像是结果集映射问题，如果是映射问题，不执行回滚时无法自动恢复的。DBA反馈，可能是TDDL(Taobao Dustributed Data Layer分布式数据访问引擎)层对Select * 的解析逻辑引起DDL变更的不兼容。我们的任务就是确认问题发生的真正原因和对以后的指导意义。

行动（分析过程）：

　　1. TDDL在执行的时候，碰到select *,会从数据库表中解决出对应的全部字段：取第一个库的第一个表进行解析，解析之后，会缓存结果。替换*，然后在吧解析后的SQL语句交到目标数据库执行。

　　2. 在第一个库变更后，TDDL拿到最新的字段列表，后续一段时间内的查询，都直接用带有新增字段的SQL语句提交到数据库执行；由于有部分数据库还没执行变更，没有新的字段，导致数据库执行出错，无法查询数据。

结论：

　　对于此问题是分库分表中，持久层框架无对select *的兼容逻辑导致。

　　但是使用select *的弊端不限于此，比如select * 查询非必需字段，会造成资源浪费甚至影响服务器性能；增加SQL的解析成本；表结构变更可能会引起字段映射问题；不会使用覆盖索引，不利于查询的性能优化等。

　　《阿里巴巴编程规约》中对于ORM规范，有明确一条强制规约：在表查询中，一律不要使用*作为查询的字段列表，需要哪些字段必须明确写明。

　　

　　很多人问过我学习方法的问题，我觉得把这些基本规约和军规仔细研读，在平时的工作中多总结实践，也可以算作一个初级或者中级程序员的亮点了。技术追求体现在解决不了的问题追究到底，了解不了的问题研究到底。项目中问题不是天天有，但是这些理论怎样和实际结合确是天天要面对的问题。

跑题时间：

　　周末，男神在看电视，我照例在旁边垫子上一边做瑜伽一边陪看电视。看的是一部很老的电影《叶问前传》。看完之后我就跟男神分享心得：“你看叶问看起来正直厚道的一个人，做起事情来很讲究方法。想搞定女友，人家先搞定女友他爹。最后女友舍身救叶问，也得到了他爹实际上的支持。”

　　女孩子和男孩子真的是来自两个星球。我看一个片子通常会想很多。但是我说出来的必定和实际发生的事情有一定的联系。但是男孩子通常是看不出来的。比如我跟男神说的上面的心得。是因为前一天晚上我俩聊天，他说看到一个姑娘比我还要超凡脱俗。

　　我说你真要和她在一起，知道了她每月要买多少化妆品你就不这么想了。女孩子多半人前人后不一样。

男神说如果在外面见到我，可能没有那么喜欢我。我在外面看起来滑头滑脑的。

　　我心想自己在外人看来基本上算是老年痴呆，但是职业习惯，见什么人说什么话。不然男神不爱吱声，我又不说话，我俩在别人看来简直一对怪胎。我也不点破，只对男神说：“你用词不当，这个词应该是‘古灵精怪’”。

　　后来他说想找个小尼姑当小老婆。看样子他还是不太认同，觉得还是应该自己是一根木头，外面看起来就应该是一根木头，也不顾及别人跟你这根木头打交道到底会不会尴尬。

　　所以我会有机会就旁敲侧击一下：做人要遵从本心，做事要灵活。