2020的个人总结
发布时间：2021-01-27 10:27:13 所属栏目：外闻 来源：互联网
导读：3. 永远不写注释，不封装代码 不要听技术总监跟你说的，要写注释，要写文档，他是为了降低你开发效率 那我们如何针对这种无理要求，并且从中分析出离职技巧呢 反其道而行之 永远不写注释，开发文档就更不要写了，都是耽误你宝贵的时间 还有变量名，函数名，
3. 永远不写注释，不封装代码不要听技术总监跟你说的，要写注释，要写文档，他是为了降低你开发效率 那我们如何针对这种无理要求，并且从中分析出离职技巧呢 反其道而行之 永远不写注释，开发文档就更不要写了，都是耽误你宝贵的时间 还有变量名，函数名，就写 a、b、c、e、f、g 除了简单以外，还自带加密效果 这样才能让你有限的时间，都用在开发上 毕竟，你写代码的时候，只有你和上帝知道逻辑是啥，没准过两天，就只有上帝知道了。 第二点，不要去封装代码，从上到下的顺着写，程序顺序执行，效率才是最高的 一个功能写一天，一个功能写一个文件 一个文件写几万行代码 然后在代码文件的末尾，写上整整齐齐的 20 个大括号，那成就感一定爆棚
不知道大括号是啥？给你个参考案例
5. 关心过业务系统里面的sql耗时吗?统计过慢查询吗?对慢查询都怎么优化过?
在业务系统中,除了使用主键进行的查询,其他的我都会在测试库上测试其耗时,慢查询的统计主要由运维在做,会定期将业务中的慢查询反馈给我们.
慢查询的优化首先要搞明白慢的原因是什么? 是查询条件没有命中索引?是load了不需要的数据列?还是数据量太大?
所以优化也是针对这三个方向来的,
6. 上面提到横向分表和纵向分表,可以分别举一个适合他们的例子吗?
横向分表是按行分表.假设我们有一张用户表,主键是自增ID且同时是用户的ID.数据量较大,有1亿多条,那么此时放在一张表里的查询效果就不太理想.我们可以根据主键ID进行分表,无论是按尾号分,或者按ID的区间分都是可以的. 假设按照尾号0-99分为100个表,那么每张表中的数据就仅有100w.这时的查询效率无疑是可以满足要求的.
纵向分表是按列分表.假设我们现在有一张文章表.包含字段
id-摘要-内容 .而系统中的展示形式是刷新出一个列表,列表中仅包含标题和摘要,当用户点击某篇文章进入详情时才需要正文内容.此时,如果数据量大,将内容这个很大且不经常使用的列放在一起会拖慢原表的查询速度.我们可以将上面的表分为两张. id-摘要 , id-内容 .当用户点击详情,那主键再来取一次内容即可.而增加的存储量只是很小的主键字段.代价很小.
当然,分表其实和业务的关联度很高,在分表之前一定要做好调研以及benchmark.不要按照自己的猜想盲目操作.
7. 什么是存储过程？有哪些优缺点？
存储过程是一些预编译的SQL语句。1、更加直白的理解：存储过程可以说是一个记录集，它是由一些T-SQL语句组成的代码块，这些T-SQL语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后再给这个代码块取一个名字，在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块，执行效率比较高,一个存储过程替代大量T_SQL语句 ，可以降低网络通信量，提高通信速率,可以一定程度上确保数据安全
但是,在互联网项目中,其实是不太推荐存储过程的,比较出名的就是阿里的《Java开发手册》中禁止使用存储过程,我个人的理解是,在互联网项目中,迭代太快,项目的生命周期也比较短,人员流动相比于传统的项目也更加频繁,在这样的情况下,存储过程的管理确实是没有那么方便,同时,复用性也没有写在服务层那么好.
8. 说一说三个范式
第一范式: 每个列都不可以再拆分. 第二范式: 非主键列完全依赖于主键,而不能是依赖于主键的一部分. 第三范式: 非主键列只依赖于主键,不依赖于其他非主键.
在设计数据库结构的时候,要尽量遵守三范式,如果不遵守,必须有足够的理由.比如性能. 事实上我们经常会为了性能而妥协数据库的设计.
9. MyBatis中的#
乱入了一个奇怪的问题…..我只是想单独记录一下这个问题,因为出现频率太高了.
# 会将传入的内容当做字符串,而有什么区别?∗∗乱入了一个奇怪的问题.....我只是想单独记录一下这个问题,因为出现频率太高了.#会将传入的内容当做字符串,而会直接将传入值拼接在sql语句中.
所以#可以在一定程度上预防sql注入攻击.
 （编辑：平凉站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
