sql优化

一切都是为了性能，一切都是为了业务 一、查询的逻辑执行顺序 (1) FROM left_table (3) join_type JOIN right_table (2) ON join_condition (4) WHERE where_condition (5) GROUP BY group_by_list (6) WITH {cube | rollup} (7) HAVING having_condition (8) SELECT (9) DISTINCT (11) top_specification select_list (9) ORDER BY order_by_list 标准的 SQL 的解析顺序为 : (1) FROM 子句 组装来自不同数据源的数据 (2) WHERE 子句 基于指定的条件对记录进行筛选 (3) GROUP BY 子句 将数据划分为多个分组 (4) 使用聚合函数进行计算 (5) 使用 HAVING 子句筛选分组 (6) 计算所有的表达式 (7) 使用 ORDER BY 对结果集进行排序 二、执行顺序 1. FROM ：对 FROM 子句中前两个表执行笛卡尔积生成虚拟表 vt1 2. ON: 对 vt1 表应用 ON 筛选器只有满足 join_condition 为真的行才被插入 vt2 3. OUTER(join) ：如果指定了 OUTER JOIN

改善SQL语句 很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如： select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan' 一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。 事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。 虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。 在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的

1、清屏操作： SQL> host cls 2、查看当前用户： SQL> show user; USER 为 "SCOTT" 当前用户为Scott 3、当前用户下的表： SQL> select * from tab; tab数据字典(管理员提供的表) TNAME TABTYPE CLUSTERID ------------------------------------------------------------ ----------------------- BONUS TABLE DEPT TABLE EMP TABLE TNAME TABTYPE CLUSTERID ------------------------------------------------------------ -------------------------- SALGRADE TABLE 4、查看表结构： SQL> desc emp; 名称 是否为空? 类型 ----------------------------------------- -------- ---------------------------- EMPNO NOT NULL NUMBER(4) 员工代号 ENAME VARCHAR2(10) 员工名字 JOB VARCHAR2(9) 职位 MGR NUMBER(4)

一、使用mysql慢查询日志对有效率问题的sql进行监控 1）开启慢查询 show variables like ‘slow_query_log’;//查看是否开启慢查询日志 set global slow_query_log_file=‘/mysql/‘; //设置慢查询日志的位置 set global log_queries_not_using_indexes=on;//设置没有使用索引的sql语句 set global long_query_time=1;//设置超过1秒的sql语句进行记录。 注意：这里设置了long_query_time后，会发现设置不成功，可能是一个bug，需要重新开启一个终端，再查询一下设置，会发现生效了。 2）查看慢查询日志的格式 # Time: 151115 6:35:08 # User@Host: root[root] @ localhost [] # Query_time: 0.007896 Lock_time: 0.006150 Rows_sent: 200 Rows_examined: 200 SET timestamp=1447540508; select * from actor; 3）工具一：mysqldumpslow mysqldumpslow -t 3 /var/lib/mysql/localhost-centos6-slow

　　最近读了 程序员的SQL金典 这本书，觉得里面的SQL注入漏洞和SQL调优总结得不错，下面简单讨论下SQL注入漏洞和SQL调优。 1. SQL 注入漏洞 　　由于“ '1'='1' ”这个表达式永远返回 true ，而 true 与任何布尔值的 or 运算的结果都是 true ，那么无论正确密码是什么“ Password='1' or '1'='1' ”的计算值永远是 true ，这样恶意攻击者就可以使用任何帐户登录系统了。这样的漏洞就被称作“ SQL 注入漏洞（ SQL Injection ）”。 　　对付 SQL 注入漏洞有两种方式：过滤敏感字符和使用参数化 SQL 。 　　1). 过滤敏感字符 　　过滤敏感字符的思路非常简单，由于恶意攻击者一般需要在输入框中输入的文本一般含有 or 、 and 、 select 、 delete 之类的字符串片段，所以在拼接 SQL 之前检查用户提交的文本中是否含有这些敏感字符串，如果含有则终止操作。 　　2).使用参数化 SQL 　　为运行时才能确定的用户名和密码设置了占位符，然后在运行时再设定占位符的值，在执行时 Java 、 C# 会直接将参数化 SQL 以及对应的参数值传递给 DBMS ，在 DBMS 中会将参数值当成一个普通的值来处理而不是将它们拼接到参数化 SQL 中 ，因此从根本上避免了 SQL 注入漏洞攻击。 2. SQL

这两天看了一下sql explain，似乎工作中我们不太重用这个命令。(但是某些场合又很重要，例如面试)。 之所以突然想起来拿出来说说，就是前两天产品经理跑过来跟我讲了一个需求：把某个客户这一年的库存出入库报表导出来。 我们wms系统是支持报表查询及导出功能的，但是仅支持三个月的查询，所以系统无法满足此项需求。 看一下sql： select wh.name '仓库名称',customer.name'所属货主',sku.sku_name '商品名称',sku.sku_code '商品编码',unit.name '单位', temp.startNum '期初库存',temp.addNum '入库',temp.subNum '出库',temp.endNum '结存', temp.reportTime '统计日期' from (SELECT id , store_id storeId , customer_id customerId , sku_id skuId, SUM(add_num) addNum, SUM(`sub_num`) subNum, SUBSTRING_INDEX(GROUP_CONCAT( start_num ORDER BY report_time ), ',',1) startNum, SUBSTRING_INDEX(GROUP_CONCAT( end_num

《SQL必知必会》 介绍需要了解的 SQL(Structured Query Language——结构化查询语言) 知识，从简单的 数据检索 入手，逐步过渡到一些较为复杂的内容，如 联结 、 子查询 、 存储过程 、 游标 、 触发器 以及 表约束 等。 第1课 了解SQL 介绍什么是 SQL ,它为什么很有用。 1.1 数据库基础 1.1.1 数据库 数据库 是一个以某种 有组织 的方式存储的数据集合(通常是一个文件或一组文件)。 最简单的办法是将数据库想象为一个文件柜。这个文件柜是一个存放数据的物理位置，不管数据是什么，也不管数据是如何组织的。 数据库软件应成为 数据库管理系统DBMS 。 数据库 是通过 DBMS 创建和操纵的容器。 1.1.2 表 文件称为表。 表 是一 结构化 的文件，可用来存储 某种特定类型 的数据。 表可以保存顾客清单、产品目录、或者其他信息清单。 数据库中的每个表都有一个名字来标识自己。这个名字是 唯一的 ，即数据库中没有其他表具有相同的名字。 表具有一些特性， 这些特性定义了数据在表中如何存储，包含存储什么样的数据，数据如何分解，各部分信息如何命名等信息。 描述表的这组信息就是所谓的 模式schema ，模式可以用来描述数据库中特定的表，也可以用来描述整个数据库(和其中表的关系)。 模式 ：关于数据库和表的布局及特性的信息。 1.1.3

QQ 1285575001 Wechat M010527 技术交流 QQ群599020441 纪年科技aming 1.设计app架构 1.梳理app业务流程 2.整理业务流程可能遇到的问题 3.根据问题，探讨可执行的解决方案 4. app后台 初步架构 ：3中所有技术进行有机融合 api编写： 1.api的作用（功能） 2.api需要输入的参数 3.api返回的数据 2.服务器选择 1.传统的IDC 在传统的IDC，要加cpu或内存，流程如下: 　　1.和客户经理商商谈所需硬件的价格 　　2.汇款过去，等IDC的财务确认 　　3.确认后，等待IDC安排工作人员升级硬件 　　这个流程走一次，最少也要1至2天。延迟了1至2天升级硬件，怎么保证可以快速应付爆发的业务 2.云服务器 升级硬件: 1.在用户后台选择需要的硬件配置 　　2.通过网络支付 　　3.重启服务器，升级就完成了。如果只是升级带宽，甚至不用重启。 　　整个过程合起来不用5分钟，简单，快捷，方便。 　　而且，现在的云服务器提供商，除了服务器外，还提供下面的服务： 　　负载均衡 　　云数据库 　　云内存存储 　　这些服务在app上线初期，在一台服务器上自己搭建就行了， 　　但随着app的发展，这些服务都需要部署在不同的服务器。 　　 　　规模的增大，也要面对高可用，高并发，监控报警等问题。 　　这些问题如果都要后端人员处理

1、把MySQL当个黑盒子一样执行SQL语句 上一讲我们已经说到，我们的系统采用数据库连接池的方式去并发访问数据库，然后数据库自己其实也会维护一个连接池，其中管理了各种系统跟这台数据库服务器建立的所有连接 我们先看下图回顾一下 当我们的系统只要能从数据库连接池获取到一个数据库连接之后，我们就可以执行增删改查的SQL语句了 从上图其实我们就可以看到，我们可以通过数据库连接把要执行的SQL语句发送给MySQL数据库。 然后呢？大部分同学了解到这个程度就停下来了，然后大家觉得要关注的可能主要就是数据库里的表结构，建了哪些索引，然后就按照SQL语法去编写增删改查SQL语句，把MySQL当个黑盒子去执行SQL语句就可以了。 我们只知道执行了insert语句之后，在表里会多出来一条数据；执行了update语句之后，会对表里的数据进行更改；执行了delete语句之后，会把表里的一条数据删除掉；执行了select语句之后，会从表里查询一些数据出来。 如果语句性能有点差？没关系，在表里建几个索引就可以了！可能这就是目前行业内很多工程师对数据库的一个认知，完全当他是个黑盒子，来建表以及执行SQL语句。 但是大家既然跟着我开始学习了，从现在开始就要打破这种把数据库当黑盒子的认知程度，要深入底层，去探索数据库的工作原理以及生产问题的优化手段！ 2、一个不变的原则：网络连接必须让线程来处理

Oracle中 ，in语句中可放的最大参数个数是 1000个 。之前遇到超过1000的情况，可用如下语句，但如此多参数项目会低，可考虑用别的方式优化。 select * from Table where id in(xxx,xxx...) or id in(yyy,yyy,...) mysql中 ，in语句中参数个数是 不限制 的。不过对整段sql语句的长度有了限制（ max_allowed_packet ）。默认是4M References： https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#function_in https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_allowed_packet 来源： CSDN 作者： 学亮编程手记 链接： https://blog.csdn.net/a772304419/article/details/103838176