sql优化

前段时间订阅了《Mysql实战45讲》（从原理到实战）,新的一年为自己充充电。对于这部分内容，我所知道的只来源于我大学里学习的课程《数据库原理》，在大学里学习的只是简单的查询，增加，删除，索引，锁，触发器，视图等内容。几乎没有基础的架构知识。因此在这里巩固一下原理，学习一下数据库Mysql在原理上究竟是怎样的。 首先我们一起看一个Mysql的基本架构示意图： 1、Mysql可以分为Server层和存储引擎层两部分。 2、Server层：包含连接器，查询缓存，分析器，优化器，执行器等，涵盖了MySQL的大多数核心功能区以及所有的内置函数。 ①内置函数：日期，时间，数学和加密函数等； ②所有跨存储引擎的功能都在这一层实现，例如存储过程，触发器，视图等； 3、存储引擎层：负责数据的存储和提取。 ①架构模式：插件式的，支持InnoDB（目前也是最常用的，MySQL5.5后默认存储引擎）、MyISAM、Memory等多个存储引擎。 ②create table 时不指定引擎类型，默认使用的就是InnoDB.如果使用其他类型，可以利用create table语句中使用engine=memory，等来指定使用内存引擎来创建表。不同的存储引擎数据存储方式不同，支持的功能也不同。 4、不同的存储引擎共用一个server层，结合一个例子我们从总体上了解一下各部件的功能。 mysql> select *

MySQL的存储引擎架构将查询处理与数据的存储/提取相分离。下面是MySQL的逻辑架构图： 第一层负责连接管理、授权认证、安全等等。 每个客户端的连接都对应着服务器上的一个线程。服务器上维护了一个线程池，避免为每个连接都创建销毁一个线程。当客户端连接到MySQL服务器时，服务器对其进行认证。可以通过用户名和密码的方式进行认证，也可以通过SSL证书进行认证。登录认证通过后，服务器还会验证该客户端是否有执行某个查询的权限。 第二层负责解析查询(编译SQL)，并对其进行优化(如调整表的读取顺序，选择合适的索引等)。对于SELECT语句，在解析查询前，服务器会先检查查询缓存，如果能在其中找到对应的查询结果，则无需再进行查询解析、优化等过程，直接返回查询结果。存储过程、触发器、视图等都在这一层实现。 第三层是存储引擎，存储引擎负责在MySQL中存储数据、提取数据、开启一个事务等等。存储引擎通过API与上层进行通信，这些API屏蔽了不同存储引擎之间的差异，使得这些差异对上层查询过程透明。存储引擎不会去解析SQL。 来源： https://www.cnblogs.com/yumo1627129/p/9511213.html

1.Connectors 指的是不同语言中与SQL的交互 2 Management Serveices & Utilities： 系统管理和控制工具 3 Connection Pool: 连接池 管理缓冲用户连接，线程处理等需要缓存的需求。 负责监听对 MySQL Server 的各种请求，接收连接请求，转发所有连接请求到线程管理模块。每一个连接上 MySQL Server 的客户端请求都会被分配（或创建）一个连接线程为其单独服务。而连接线程的主要工作就是负责 MySQL Server 与客户端的通信， 接受客户端的命令请求，传递 Server 端的结果信息等。线程管理模块则负责管理维护这些连接线程。包括线程的创建，线程的 cache 等。 4 SQL Interface: SQL接口。 接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface 5 Parser: 解析器。 SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的，是一个很长的脚本。 在 MySQL中我们习惯将所有 Client 端发送给 Server 端的命令都称为 query ，在 MySQL Server 里面，连接线程接收到客户端的一个 Query 后，会直接将该 query 传递给专门负责将各种 Query

如 果用户输入的是直接插入到一个SQL语句中的查询，应用程序会很容易受到SQL注入，例如下面的例子: $unsafe_variable = $_POST['user_input']; mysql_query("INSERT INTO table (column) VALUES ('" . $unsafe_variable . "')"); 这是因为用户可以输入类似VALUE"); DROP TABLE表; - ，使查询变成： INSERT INTO table (column) VALUES('VALUE'); DROP TABLE table;' 1.使用PDO(PHP Data Objects ) $stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name'); $stmt->execute(array(':name' => $name)); foreach ($stmt as $row) { // do something with $row } 2.使用mysqli 复制代码 代码如下: $stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?'); $stmt->bind_param('s', $name);

有关分页 SQL 的资料很多，有的使用存储过程，有的使用游标。本人不喜欢使用游标，我觉得它耗资、效率低；使用存储过程是个不错的选择，因为存储过程是经过预编译的，执行效率高，也更灵活。先看看单条 SQL 语句的分页 SQL 吧。 方法1： 适用于 SQL Server 2000/2005 SELECT TOP 页大小 * FROM table1 WHERE id NOT IN ( SELECT TOP 页大小 * ( 页 数 - 1 ) id FROM table1 ORDER BY id ) ORDER BY id 方法2： 适用于 SQL Server 2000/2005 SELECT TOP 页大小 * FROM table1 WHERE id > ( SELECT ISNULL ( MAX (id), 0 ) FROM ( SELECT TOP 页大小 * ( 页 数 - 1 ) id FROM table1 ORDER BY id ) A ) ORDER BY id 方法3： 适用于 SQL Server 2005 SELECT TOP 页大小 * FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY id) AS RowNumber, * FROM table1 ) A WHERE RowNumber > 页大小 * (页数 - 1 )

最近数据库tempdb暴涨，上网查询了相关介绍，总结如下：　　 tempdb全局存储内部对象，用户对象，临时表，临时对象，以及SQL Server操作创建的存储过程。每个数据库实例只有一个tempdb，所以可能存在性能以及磁盘空间瓶颈。各种形式的可用空间及过度饿DDL/DML操作都会导致tempdb负载过重。这会导致运行在服务器上不相干程序运行缓慢或者运行失败。 　　tempdb的一些常见通病如下： 　　--耗完了tempdb的所有存储空间 　　--读取tempdb时的I/O瓶颈造成的查询运行缓慢。 　　--过度的DDL操作造成在系统表上的瓶颈。 　　--分配竞争 　　在我们开始诊断问题之前，让我们首先看一下tempdb的空间都用在了哪些地方。可以分成四个主要的类比： 类别 描述 用户对象 这些是明确地由用户创建并且在系统类别中进行追踪。他们包括下面的： --表及索引 --全局性质的临时表（##t1）以及索引 --局部临时表（#t1）及索引 　　会话范围的 　　存储过程范围的 --表变量（@t1） 　　会话范围的 　　存储过程范围的 内部对象 SQL Server在运行查询的时候会创建或销毁许多语句范围的对象。这些 没有在系统类别中被追踪。他们包括以下内容： --工作文件（hash连接） --排序运行 --工作表（游标，池以及临时的大对象数据类型（LOB）存储） -

RAISERROR 返回用户定义的错误信息并设系统标志，记录发生错误。通过使用 RAISERROR 语句，客户端可以从 sysmessages 表中检索条目，或者使用用户指定的严重度和状态信息动态地生成一条消息。这条消息在定义后就作为服务器错误信息返回给客户端。 语法 RAISERROR ( { msg_id | msg_str } { , severity , state } [ , argument [ ,...n ] ] ) [ WITH option [ ,...n ] ] 参数 msg_id 存储于 sysmessages 表中的用户定义的错误信息。用户定义错误信息的错误号应大于 50,000。由特殊消息产生的错误是第 50,000 号。 msg_str 是一条特殊消息，其格式与 C 语言中使用的 PRINTF 格式样式相似。此错误信息最多可包含 400 个字符。如果该信息包含的字符超过 400 个，则只能显示前 397 个并将添加一个省略号以表示该信息已被截断。所有特定消息的标准消息 ID 是 14,000。 msg_str 支持下面的格式： % [[flag] [width] [precision] [{h | l}]] type 可在 msg_str 中使用的参数包括： flag 用于确定用户定义的错误信息的间距和对齐的代码。 代码 前缀或对齐 描述 -（减）

MySQL InnoDB特性：Double Write 一、经典Partial page write问题？ 介绍double write之前我们有必要了解partial page write（部分页失效）问题。 InnoDB的Page Size一般是16KB，其数据校验也是针对这16KB来计算的，将数据写入到磁盘是以Page为单位进行操作的。我们知道，由于文件系统对一次大数据页（例如InnoDB的16KB）大多数情况下不是原子操作，这意味着如果服务器宕机了，可能只做了部分写入。16K的数据，写入4K时，发生了系统断电/os crash ，只有一部分写是成功的，这种情况下就是partial page write问题。 有经验的DBA可能会想到，如果发生写失效，MySQL可以根据redo log进行恢复。这是一个办法，但是必须清楚地认识到，redo log中记录的是对页的物理修改，如偏移量800，写’aaaa’记录。如果这个页本身已经发生了损坏，再对其进行重做是没有意义的。MySQL在恢复的过程中检查page的checksum，checksum就是检查page的最后事务号，发生partial page write问题时，page已经损坏，找不到该page中的事务号。在InnoDB看来，这样的数据页是无法通过checksum验证的，就无法恢复。即时我们强制让其通过验证，也无法从崩溃中恢复

最近一段时间都学习mysql，将重要的知识点总结如下： 一、字段、表、索引设计规范相关 二、事务相关 三、锁相关 四、存储引擎相关 五、大表优化相关 六、索引优化相关 七、语句优化相关 一、字段、表、索引设计规范 1、字段设计规范 ① 字段类型优先选择符合存储需要的最小类型 字段类型优先级：整型>date;time >enum>char;varchar>blob 原因：整型，time运算快，节省内存；enum列内部是用整型存储的，char，varchar要考虑字符集的转换和排序的校对集，速度慢；blob无法使用临时表。 ② 够用就行（如smallint，varchar(N)） 原因：大的字段浪费内存，影响速度，如varchar(10),varchar(300),虽然存储的内容一样，但是,在表联查时，varchar(300)要花更多内存 ③ 尽量避免使用允许为null() 原因：null不利于索引，要用特殊的字节标注，在磁盘上占的空间其实更大 例子：建两个相同字段的表，一个允许为null，一个不允许。可以发现为null的索引更大些。 ④ 避免使用ENUM类型 修改ENUM值需要使用ALTER语句 ENUM类型的ORDER BY操作效率低，需要额外操作 禁止使用数值作为ENUM的枚举值 ⑤ 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间 TIMESTAMP

教学视频：https://edu.csdn.net/course/detail/26238/325885 一，简介 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。 适用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92标准的数据库。 核心概念 1.SQL 逻辑表 水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为10张表，分别是 t_order_0 到 t_order_9 ，他们的逻辑表名为 t_order 。 真实表 在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到 t_order_9 。 数据节点 数据分片的最小单元。由数据源名称和数据表组成，例： ds_0.t_order_0 。 绑定表 指分片规则一致的主表和子表。例如： t_order