艾锑知识 | 8种SQL错误用法

2020-02-18 15:46 作者：admin 浏览量：

这几天如果大家关注疫情数据的变化，可以看到新增确诊病例在持续下降，这意味着疫情很快就会结束，大家再也不用在家办公了，到不是在家工作有什么不好，但人类发明工作不简简单单只是为了实现结果的达成，还有一个非常重要的因素就是人与人之间的联结，这是人类内在价值的需求，透过工作与人接触，共同感受彼此的能量流动，从而达到自我价值的实现，这就像演员都渴望登上奥斯卡的舞台，来实现自我角色的认可一样。
 
 
在家办公，毕竟是家，松、散、懒以及无所谓的态度会随时产生，我相信不是每个人都会这样，但大部分人会如此，因为家本来就是放松的能量场，接下来大家即将回到公司，回到自己的工作岗位，难免会把在家的状态带入工作中，如果每个人都是这样的状态，企业很快会陷入新的窘境，所以没有状态，也不会有好的结果，状态就是一切。
 
团队的势气决定企业整体的战斗力，那如何调整陆陆续续回来的团队成员呢？
 
 
艾锑无限对中小企业有三条建议：
 
第一，重新梳理整个企业的战略，疫情的发生，是否给你企业带来了变化？如果有那是什么？是否需要调整自己原有的战略方向来应对疫情发生后的影响？
 
第二，重新明确每个人的目标和目的，目标就是重回企业的人要干什么？干到什么程度？什么时间可以看到这个结果的发生？目的就是为什么要实现这个目标？这个目标与自己的意义是什么？与企业的意义又是什么？达成了会怎么样？达不成又会怎么样？
 
只有清晰这些问题，才会让回到工作岗位的人快速改变自己的状态投入到接下来的工作中，只有积极的状态投入工作才会有积极的成果发生，反之依然。
 
第三，企业高管与员工建立一对一的对话机制，因疫情的影响，每个人心理或多或少都会产生一些内在的变化，作为企业的高层管理人员，最好与企业内部员工一对一的进行沟通，去了解在这个过程中员工受到的影响和产生的变化，以便接下来更好的调整他们的状态，因为如果他们的心没有回来，企业的要求和制度带来的也都是大家没有能量的重复和机械的工作，最终也很难带来好的结果。
 
以上三点是企业管理者需要重视的，当然身为企业的一员无论是谁也都需要重新审视自己的状态，因为这关系着企业接下来的生、死、存、亡，能量是企业持续发展的源泉，以上所有的目的都是为了聚合企业人的能量，重新点燃大家面对工作的激情和信心，这将是企业至胜的法定。
 
当然这只是我们一家之言，每家企业可根据自身的情况做出相应的调整和改变。
 
以上三点做为每一家企业的管理者都有必要重视起来，因为这关系着企业接下来的生、死、存、亡，当然这只是我们一家之言，可根据自身的情况做出相应的调整和改变。
 
那为什么我们会有这样的思考，因为艾锑无限是一家企业互联网”云”解决方案服务平台，企业在初创时经历了2003年的非典，后来又经历了2008年的经济危机以及2016年互联网创业大潮，生生死死，几经沉浮，最终发现上述三点是生死线中最重要的，所以愿意分享给大家，期望这次疫情大家不仅能渡过难关，更能看见大家在这个过程中强而有力的领导力，让自己企业力挽狂澜，让自己的工作更上一层楼，让自己的生活在2020年更精彩。
 
在这次疫情后各个企业恢复的过程中，艾锑无限还能为大家做的就是免费为中小企业提供相应的IT服务，以下是艾锑无限可以提供服务的内容，如果大家有相应的需求，可以打下面的电话与我们的企业相关人员联系，我们一定会尽全力帮助大家渡过难关。
   
 
历经10几年,艾锑无限服务了5000多家中小企业并保障了几十万台设备的正常运转，积累了丰富的企业IT紧急问题和特殊故障的解决方案，我们为您的企业提供的IT服务分为三大版块:
 
第一版块是保障性IT外包服务:如电脑设备运维，办公设备运维，网络设备运维，服务器运维等综合性企业IT设备运维服务。
 
第二版块是功能性互联网外包服务:如网站开发外包，小程序开发外包，APP开发外包，电商平台开发外包，业务系统的开发外包和后期的运维外包服务。
 
第三版块是增值性云服务外包:如企业邮箱上云，企业网站上云，企业存储上云，企业APP小程序上云，企业业务系统上云，阿里云产品等后续的云运维外包服务。
   
更多服务也可以登录艾锑无限的官网: www.bjitwx.com 查看详细说明。

每家企业都有着不同的人，每个人都有着不一样的思考，所以企业不需要统一所有人的思维，企业只需要统一所有人的心，因为只要心在一起了，能量就会合一，能量合一企业将无所不能。
 
相信这次疫情带给中国企业的不仅仅是灾难，更有可能的是历练，这几年经济发展如此快速，大部分中小企业的成长都是随着国家政策及整个社会的大势起来的，没有经过太多的挑战和困难，所以存活周期也会很短，从2016年大众创业，万众创新倡导下成立了上千万家企业，但真正存活下来的就只有几万家，这样的结果即不能给国家带来稳定持续发展的动力，也不能为社会创造更大的价值，反而让更多的人投机取巧，心浮气躁，沉不下来真正把一件事做好，做到极致。
 
所以这次疫情也会让大部分企业重新思考，问问自己，为什么要创立这家企业，想为这个国家和社会带来的是什么？企业真正在创造的是什么？如何做才能让社会因自己的企业变得更好？.....
 
当企业真正去思考，用心去创造价值的时候，也就是人们幸福快乐的时候，因为再也不用担心假货、次货、买到不好的产品，更不用担心环境被污染，大气被破坏，疫情即是一场灾难，又是重新成就中国企业的一次机会，让全世界人觉醒，生命只有一次，我们要如何做才能不枉此生呢？
 
 
你对世界微笑，世界绝不会对你哭，希望大家都能积极乐观起来，让自己、自己的家人、自己的企业、还有自己的国家都快乐起来，把焦点、意识、能量放在我们想要什么上，而不是不要的事情上，我相信，就在不久的将来，我们一定会看到一个富强、文明、健康的中国以及一个和谐友爱的世界。
 
万物同体，能量合一，最后无论你是中小企业，还是大型国有企业，只要你选择艾锑无限，我们就一定全力以赴帮助大家渡过难关，服务有限，信息无限，透过全体艾锑人的努力，为您收集最有效的IT技术信息，让您企业更快速解决遇到的IT问题：
 
艾锑知识 | 8种SQL错误用法


1. LIMIT 语句
分页查询是最常用的场景之一，但也通常也是最容易出问题的地方。比如对于下面简单的语句，一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。
好吧，可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时，程序员仍然会抱怨：我只取10条记录为什么还是慢？要知道数据库也并不知道第1000000条记录从什么地方开始，即使有索引也需要从头计算一次。出现这种性能问题，多数情形下是程序员偷懒了。在前端数据浏览翻页，或者大数据分批导出等场景下，是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下： 在新设计下查询时间基本固定，不会随着数据量的增长而发生变化。
 
2. 隐式转换
SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句： 其中字段 bpn 的定义为 varchar(20)，MySQL 的策略是将字符串转换为数字之后再比较。函数作用于表字段，索引失效。上述情况可能是应用程序框架自动填入的参数，而不是程序员的原意。现在应用框架很多很繁杂，使用方便的同时也小心它可能给自己挖坑。
 
3. 关联更新、删除
虽然 MySQL5.6 引入了物化特性，但需要特别注意它目前仅仅针对查询语句的优化。对于更新或删除需要手工重写成 JOIN。 比如下面 UPDATE 语句，MySQL 实际执行的是循环/嵌套子查询（DEPENDENT SUBQUERY)，其执行时间可想而知。
 
执行计划：重写为 JOIN 之后，子查询的选择模式从 DEPENDENT SUBQUERY 变成 DERIVED，执行速度大大加
快，从7秒降低到2毫秒 执行计划简化为：


 
4. 混合排序
MySQL 不能利用索引进行混合排序。但在某些场景，还是有机会使用特殊方法提升性能的。 执行计划显示为全表扫描： 由于 is_reply 只有0和1两种状态，我们按照下面的方法重写后，执行时间从1.58秒降低到2毫秒。
5. EXISTS语句
MySQL 对待 EXISTS 子句时，仍然采用嵌套子查询的执行方式。如下面的 SQL 语句： 执行计划为： 去掉 exists 更改为 join，能够避免嵌套子查询，将执行时间从1.93秒降低为1毫秒。
新的执行计划： 6. 条件下推
外部查询条件不能够下推到复杂的视图或子查询的情况有：

• 聚合子查询；
• 含有 LIMIT 的子查询；
• UNION 或 UNION ALL 子查询；
• 输出字段中的子查询；

如下面的语句，从执行计划可以看出其条件作用于聚合子查询之后 确定从语义上查询条件可以直接下推后，重写如下： 执行计划变为：  
7. 提前缩小范围
先上初始 SQL 语句： 数为90万，时间消耗为12秒。 由于最后 WHERE 条件以及排序均针对最左主表，因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下，执行时间缩小为1毫秒左右。 再检查执行计划：子查询物化后（select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万，但是利用了索引以及 LIMIT 子句后，实际执行时间变得很小。
8. 中间结果集下推
 
再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件)： 那么该语句还存在其它问题吗？不难看出子查询 c 是全表聚合查询，在表数量特别大的情况下会导致整个语句的性能下降。其实对于子查询 c，左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下，执行时间从原来的2秒下降到2毫秒。 但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销，还使得
整个语句显的繁杂。使用 WITH 语句再次重写：  
总结
数据库编译器产生执行计划，决定着SQL的实际执行方式。但是编译器只是尽力服务，所有数据库的编译器都不是尽善尽美的。上述提到的多数场景，在其它数据库中也存在性能问题。了解数据库编译器的特性，才能避规其短处，写出高性能的SQL语句。程序员在设计数据模型以及编写SQL语句时，要把算法的思想或意识带进来。编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担 。