大家好，今天小编来为大家解答sql版本低有没有影响这个问题，sql为什么不建议用很多人还不知道，现在让我们一起来看看吧！
本文目录
为什么SQL语句不按执行顺序写
非常感谢悟空问答邀请我回答，“为什么SQL语句不按执行顺序写”这个问题，我会从2个方面进行说明，为什么不按照执行顺序去写sql语句
按照执行顺序写SQL语句难度高如果让一个程序猿按照sql执行顺序去写一个标准sql语句，难度非常大，而且不符合人类书写思维和习惯，在这里先介绍一下Select语句完整的执行顺序：
from子句组装来自不同数据源的数据where子句基于指定的条件对记录行进行筛选groupby子句将数据划分为多个分组使用聚集函数进行计算使用having子句筛选分组计算所有的表达式select的字段使用orderby对结果集进行排序SQL语言不同于其他编程语言的最明显特征是处理代码的顺序。在大多数据库语言中，代码按编码顺序被处理。但在SQL语句中，第一个被处理的子句式FROM，而不是第一出现的SELECT，我来书写一个例子
selectcount(depno),depnofromtestwheredepno='001'groupbydepnohvingcount(depno)>2orderbydepno;
如果这个语句按照上面的执行顺序来编写，大家看看会变成什么
fromtestwheredepno='001'groupbydepnocount(depno)havingcount(depno)>2selectcount(depno),depnoorderbydepno;
这个语句估计没人看的懂了，或者说看起来非常的费劲。
书写效率标准的sql语句写法发展也有好几十年了，经过这么长时间的发展，也经过商业数据库和客户的考验，证明现在的sql语法是非常适合人类学习和书写的。
sql版本低有没有影响
SQL版本的低级可能会对数据库系统的功能和性能产生一些影响。以下是一些可能的影响：
功能限制：较早的SQL版本可能不支持一些高级的功能，例如存储过程、触发器、事务处理等。这可能会限制数据库系统的功能和可扩展性，使得无法实现一些复杂的应用程序。
兼容性：由于不同版本的SQL语言之间存在差异，因此如果使用较旧的SQL版本编写的应用程序，可能无法在较新的数据库系统上运行。因此，如果需要升级数据库系统或更改应用程序，可能需要修改代码或进行额外的适配工作。
性能影响：较早的SQL版本可能不支持一些优化技术，例如索引、查询优化器等。这可能会导致查询性能下降，使得无法处理大量数据或需要大量计算资源的复杂查询。
安全漏洞：较早的SQL版本可能存在一些已知的安全漏洞，这些漏洞可能已被修补程序所修复。如果使用受信任的修补程序或更新到新版本的SQL语言，可以减少安全漏洞的风险。
综上所述，尽可能使用最新版本的SQL以确保最大的功能、兼容性、性能和安全性。如果可能的话，应该考虑将数据库系统升级到最新的SQL版本，以便获得更好的性能和功能。
SQL数据库中如果表名中列名为汉字,有什么不好吗
1.有不好的地方。2.因为在SQL数据库中，表名和列名通常是用来标识和操作数据的重要元素，使用汉字作为表名和列名可能会导致以下问题：a)可读性差：汉字表名和列名可能对非汉字读者来说不易理解，降低了代码的可读性和可维护性。b)兼容性问题：某些数据库管理系统可能对汉字的支持不完善，可能会导致一些操作和查询出现问题。c)命名规范不统一：使用汉字命名容易导致命名规范不统一，不利于团队协作和代码维护。3.为了避免上述问题，通常建议在SQL数据库中使用英文或者数字作为表名和列名，这样可以提高代码的可读性和可维护性，同时也能够保证兼容性和命名规范的统一。如果需要使用汉字来表示某些特定的含义，可以考虑使用注释或者添加说明来其含义，而不是直接作为表名和列名。
是否应该将复杂的逻辑写进sql中
软件项目本身会有很多分类。在IT传统项目/内部系统中，往往仍有很多项目采用复杂逻辑写入sql或存储过程的做法。当然并不代表这个做法是最佳的。
还是先抛出结论。
单单从技术角度讲，是绝不应该将复杂逻辑写入sql的。如果题主对原因不敢兴趣，看到这里就可以了。下面我会简单解释下这么做的一些原因。
首先，先说说传统IT服务类项目。类似，电信，政企，银行，XXX管理系统，XXX运维系统。
这类项目往往是国企，事业单位，外包，公司内部，系统表现就是低频高熵(即：系统的并发和用户量不高，但是每次请求返回的数据量较大)。这类项目由于用户少，系统压力并不是特别大。采用复杂的sql语句去直接把压力扔给数据库，并不会有太大的问题。
另一方面，由于外包项目和内部系统，往往存在开发周期短，资金供给不太足，所以一般会采用这种较快的开发方式。复杂的数据处理，逻辑过滤，都会一股脑的扔给数据库去处理。但是，单单从技术角度看，从系统性能和单机的用户容量上看，这么做，显然不是特别科学。完全可以用更少的机器，去支持更多的用户。
其次，常见的互联网技术架构。类似在线电商，O2O，生鲜等。
互联网公司由于大多系统是高频低熵(即系统的并发和用户量巨大，但是每个用户返回的数据只和自己订单相关，数据量少)。而高并发的系统瓶颈，往往在网络IO和磁盘IO上。数据库的吞吐，很快会成为系统性能的瓶颈。因此，对于高并发大流量的系统，我们要尽可能的减少数据库压力，使单次查询的时间尽可能短。缓存和分库分表等一系列操作，都是为了尽可能的减少数据库的读写压力。
这里贴上一张常见的互联网公司数据切片的操作。
最后，作为技术人员，我推荐采用互联网技术架构的思路去解决项目中的数据库问题。以最少的成本，性能最好的优化代码，才能提高相应的技术能力。如果所有问题丢sql，性能不够加机器，同样能解决问题，但显然不是一个技术人员应有的追求。
当然至于代码的可读性，可维护性等其他的，这些也算是原因之一，但并非是主要原因。
对互联网公司技术架构设计有兴趣，欢迎查看我之前的回答，里面有相关的公司架构设计发展的历程。有问题随时讨论，谢谢。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！