先介绍一下 MySQL 数据库开发的三十六条军规, 这里只介绍核心的, 具体内容大家可以自行百度, 这是从底层开发人员到管理者必须知道规范出自 58 赶集
写在前面的话:
总是在灾难发生后, 才想起容灾的主要性;
总是在吃过亏后, 才记得有人提醒过
核心军规:
不在数据库做计算, CPU 计算务必移至业务层;
控制单表数据量, 单表记录控制在千万级;
控制列数量, 字段数控制在 20 以内;
平衡范式与冗余, 为提高效率可以牺牲范式设计, 冗余数据;
拒绝 3B(big), 大 SQL 大数据大批量
介绍两个例子这个适合用 STAR 法则 STAR 法则是情境 (situation) 任务 (task) 行动 (action) 结论 (result) 四项的缩写 STAR 法则是一种常常被面试官使用的工具一般常说的开放性的问题, 就是设立一个场景怎样解决问题基本用的是这种工具
案例 1:
以下是我们组发生的一个真实例子, 具体操作和调研是由我两个同事实施的
情境:
核心交易目前在进行代码重构, 数据模型的重构是其中重要的一个环节一天我们同事在进行 DDL(Data Defination Lauguage)的变更, 由于两个字段比较相近, 但是其中一个是原有字段不可为空, 另外一个是新增字段, 允许为空, 结果空字段被赋值给了非空字段, DDL 执行导致大量异常 DDL 变更回滚后日志恢复正常
任务:
从 java 程序到连接 mysql 数据库用到了 atlasmybatis 数据库驱动到达 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 规范, 有明确一条强制规约: 在表查询中, 一律不要使用 * 作为查询的字段列表, 需要哪些字段必须明确写明
很多人问过我学习方法的问题, 我觉得把这些基本规约和军规仔细研读, 在平时的工作中多总结实践, 也可以算作一个初级或者中级程序员的亮点了技术追求体现在解决不了的问题追究到底, 了解不了的问题研究到底项目中问题不是天天有, 但是这些理论怎样和实际结合确是天天要面对的问题
跑题时间:
周末, 男神在看电视, 我照例在旁边垫子上一边做瑜伽一边陪看电视看的是一部很老的电影叶问前传看完之后我就跟男神分享心得: 你看叶问看起来正直厚道的一个人, 做起事情来很讲究方法想搞定女友, 人家先搞定女友他爹最后女友舍身救叶问, 也得到了他爹实际上的支持
女孩子和男孩子真的是来自两个星球我看一个片子通常会想很多但是我说出来的必定和实际发生的事情有一定的联系但是男孩子通常是看不出来的比如我跟男神说的上面的心得是因为前一天晚上我俩聊天, 他说看到一个姑娘比我还要超凡脱俗
我说你真要和她在一起, 知道了她每月要买多少化妆品你就不这么想了女孩子多半人前人后不一样
男神说如果在外面见到我, 可能没有那么喜欢我我在外面看起来滑头滑脑的
我心想自己在外人看来基本上算是老年痴呆, 但是职业习惯, 见什么人说什么话不然男神不爱吱声, 我又不说话, 我俩在别人看来简直一对怪胎我也不点破, 只对男神说: 你用词不当, 这个词应该是古灵精怪
后来他说想找个小尼姑当小老婆看样子他还是不太认同, 觉得还是应该自己是一根木头, 外面看起来就应该是一根木头, 也不顾及别人跟你这根木头打交道到底会不会尴尬
所以我会有机会就旁敲侧击一下: 做人要遵从本心, 做事要灵活
来源: https://www.cnblogs.com/xiexj/p/8454209.html