sql优化

目录 一、 选择合适的存储引擎: InnoDB 1.1 怎样将现有的 MyISAM 数据库转换为 InnoDB: 1.2 为每一个表分别创建 InnoDB FILE： 二、 保证从内存中读取数据。讲数据保存在内存中 2.1 足够大的 innodb_buffer_pool_size 2.1.1 怎样确定 innodb_buffer_pool_size 足够大。数据是从内存读取而不是硬盘？ 2.1.2 server上是否有足够内存用来规划 2.2 数据预热 2.3 不要让数据存到 SWAP 中 三、定期优化重建数据库 四、降低磁盘写入操作 4.1 使用足够大的写入缓存 innodb_log_file_size 4.2 innodb_flush_log_at_trx_commit 4.3 避免双写入缓冲 五、提高磁盘读写速度 六、充分使用索引 6.1 查看现有表结构和索引 6.2 加入必要的索引 6.2.1 比方，优化用户验证表： 6.2.2 使用自己主动加索引的框架或者自己主动拆分表结构的框架 七、分析查询日志和慢查询日志 八、激进的方法。使用内存磁盘 九、用 NOSQL 的方式使用 MYSQL 十、其它 MYSQL 应该是最流行了 WEB 后端数据库。WEB 开发语言近期发展非常快，PHP， Ruby, Python, Java 各有特点，尽管 NOSQL 近期越來越多的被提到

MySQL索引以及优化总结 B树和B+树结构 MyISAM与InnoDB 的存储区别 索引的本质 联合索引（最左前缀匹配原则） B树和B+树结构 MySQL为什么要用B+树：与二叉树和红黑树不同的是B树的节点上可以存放多个索引，这样降低了树的高度，使得查询效率更高。B+树在B树的基础上加以改进，父节点存放冗余索引，叶子节点存放所有的索引和数据（可能是索引对应行数据的文件地址或，也可能是整行数据），并且节点之间通过指针相互关联，查询效率进一步提升。 MyISAM与InnoDB 的存储区别 InnoDB 是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高，但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，否则其他索引也会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针，主键索引和辅助索引是独立的。 索引的本质 为什么索引一般选用tree而不用hash：因为hash只使用与指定值的查找而范围查找就需要全表扫描。 联合索引（最左前缀匹配原则） 最左前缀匹配原则，是一个非常重要的原则，可以通过以下这几个特性来理解。 1、对于联合索引，MySQL 会一直向右匹配直到遇到范围查询（> ， < ，between，like）就停止匹配。比如 a = 3 and b = 4 and c > 5 and d

随着业务负载的不断加重，容器化、虚拟化也成为各类在线应用必须要具备的能力。对于分布式数据库，容器化也是提升快速部署、提高运维效率的一个很好的路径。 我们重新优化了 Docker部署的方式，帮助大家更快的上手SequoiaDB集群，本文就将介绍基于 Docker 的SequoiaDB分布式集群快速部署。 1.集群配置 我们将在六个容器中部署一个多节点，高度可用的 SequoiaDB 集群，如下所示: （本文以 SequoiaDB v3.2.3 版本为例） 该集群包括一个协调器节点、一个目录节点、三个数据组，每个数据组有三个副本数据节点和一个 MySQL 实例节点。 环境 ​​​​​​​ OS : Ubuntu 18 Docker Version : 18.09.7 Docker Compose Version: 1.25.3 Database Version : SequoiaDB 3.2.3 MySql Client: Sequoiasql-mysql Cluster Deployment : 1 coordinator, 1 catalog, 3 data nodes, and 1 MySQL instance 2.1 Docker安装 2.1.1 Docker 对于在不同平台上的 Docker 安装，用户可以参阅 Docker 安装指南。 sudo apt-get

索引目的 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？ 索引原理 除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂许多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段……这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的，数据库实现比较复杂，数据保存在磁盘上

前言 工作的这些年发现一个比较奇怪的现象就是身边无论是工作十多年的老兵，还是初级刚入行的程序员，在高谈阔论技术和趋势的时候都是人工智能，大数据，区块链，各种框架，语言，算法，AI，BI，CI，DI…… 等等，倒是发现很少有人关注数据库，不知道是因为数据库感觉太低端还是太低调，总是不容易被人提起 技术就是这样，不太关注的地方就不会重视，越是不被重视的地方，掉进坑里的概率就会越大，所以就在这里给大家简单聊聊在使用数据库过程中有哪些防掉坑指南，也可以对刚入行的小朋友有一个提醒的作用，万丈高楼平地起，一定要先打好基础再去考虑上层的建筑，不要舍本逐末 本章主要分以下四个小节（预计读完 5 分钟左右）： 数据库为什么重要 数据库有哪些使用技巧 数据库有哪些容易掉进去的坑？ 深入学习数据库的建议 数据库为什么重要 很多人在开发过程中不太关注数据库，对于表结构的设计也没什么讲究大多属于“能用就行”，但是根据作者将近十年的开发经验来看的话，只要你是从事 Web 相关领域开发你就无法避免不和数据库打交道， 在Web开发中大多功能操作本质上都是对数据库进行操作 ，不管你用是 Pythod，Java，Ruby 等语言进行 Web 开发，你其实都是在面向数据库进行编程，很多 Web 框架作者为了避免程序员接触数据库的相关知识甚至还封装了一层 ORM （Object Relational Mapping

关于 order by 的查询优化可以看一下: MySQL ORDER BY/LIMIT performance: late row lookups 主要介绍了两个方法： 第一个是 FORCE INDEX (PRIMARY) ：这个理解很直白就是强行加索引 第二个是 late row lookups ，也就是文章的重点，其实就是先构造一个只有id的子查询，然后再 join 一起。这样极大的提高效率。如下示例代码， o 是通过你的表和只有id查询出来的临时字表， l 是要join一起包含所有字段的表。 explain SELECT xx,xxx,.... FROM ( SELECT id FROM <你的表> ORDER BY id LIMIT <返回条数的范围> ) o JOIN <你的表> l ON l.id = o.id ORDER BY l.id 来源： https://www.cnblogs.com/iathanasy/p/12425889.html

都属于开放源码的一员，性能和功能都在高速地提高和增强。MySQL AB的人们和PostgreSQL的开发者们都在尽可能地把各自的数据库改得越来越好，所以对于任何商业数据库使用其中的任何一个都不能算是错误的选择。 PostgreSQL : 免费 原则: 对于一个数据库，稳定性和速度并不能代表一切。对于一个成熟的数据库，稳定性肯定会日益提供。而随着硬件性能的飞速提高，速度也不再是什么太大的问题。 1 架构对比 MySQL： 多线程 PostgreSQL： 多进程 多线程架构和多进程架构之间没有绝对的好坏，例如oracle在unix上是多进程架构，在windows上是多线程架构。 PG 的有多种集群架构可以选择，plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。 pgsql对于numa架构的支持比mysql强一些，比MYSQL对于读的性能更好一些，pgsql提交可以完全异步，而mysql的内存表不够实用（因为表锁的原因） 2 对存储过程[1]及事务的支持能力 1） MySQL对于无事务的MyISAM表，采用表锁定，一个长时间运行的查询很可能会长时间地阻碍对表的更新，而PostgreSQL不存在这样的问题。 2） PostgreSQL支持存储过程

参考资料： 数据库MySQL经典面试题之SQL语句 -- 创建表------------------------------------------------------------ -- 学生表 drop table student ; create table Student ( SID varchar ( 10 ) , Sname varchar ( 10 ) , Sage datetime , Ssex varchar ( 10 ) ) ; -- SID 学生编号,Sname 学生姓名,Sage 出生年月,Ssex 学生性别 desc Student ; insert into Student values ( '01' , '赵雷' , '1990-01-01' , '男' ) ; insert into Student values ( '02' , '钱电' , '1990-12-21' , '男' ) ; insert into Student values ( '03' , '孙风' , '1990-05-20' , '男' ) ; insert into Student values ( '04' , '李云' , '1990-08-06' , '男' ) ; insert into Student values ( '05' , '周梅' , '1991

一、 mysql分区简介 数据库分区 数据库分区是一种物理数据库设计技术。虽然分区技术可以实现很多效果，但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减sql语句的响应时间，同时对于应用来说分区完全是透明的。 MYSQL的分区主要有两种形式：水平分区和垂直分区 水平分区（HorizontalPartitioning） 这种形式的分区是对根据表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。 所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。水平分区一定要通过某个属性列来分割。常见的比如年份，日期等。 垂直分区（VerticalPartitioning） 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应所有行。 可以用 showvariables like '%partition%'; 命令查询当前的mysql数据库版本是否支持分区。 分区的作用：数据库性能的提升和简化数据管理 在扫描操作中，mysql优化器只扫描保护数据的那个分区以减少扫描范围获得性能的提高。 分区技术使得数据管理变得简单，删除某个分区不会对另外的分区造成影响，分区有系统直接管理不用手工干预。 mysql从5.1版本开始支持分区

Transact-SQL中的存储过程，非常类似于Java语言中的方法，它可以重复调用。当存储过程执行一次后，可以将语句缓存中，这样下次执行的时候直接使用缓存中的语句。这样就可以提高存储过程的性能。 Ø 存储过程的概念 存储过程Procedure是一组为了完成特定功能的SQL语句集合，经编译后存储在数据库中，用户通过指定存储过程的名称并给出参数来执行。 存储过程中可以包含逻辑控制语句和数据操纵语句，它可以接受参数、输出参数、返回单个或多个结果集以及返回值。 由于存储过程在创建时即在数据库服务器上进行了编译并存储在数据库中，所以存储过程运行要比单个的SQL语句块要快。同时由于在调用时只需用提供存储过程名和必要的参数信息，所以在一定程度上也可以减少网络流量、简单网络负担。 1、 存储过程的优点 A、 存储过程允许标准组件式编程 存储过程创建后可以在程序中被多次调用执行，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，但对应用程序源代码却毫无影响，从而极大的提高了程序的可移植性。 B、 存储过程能够实现较快的执行速度 如果某一操作包含大量的T-SQL语句代码，分别被多次执行，那么存储过程要比批处理的执行速度快得多。因为存储过程是预编译的，在首次运行一个存储过程时，查询优化器对其进行分析、优化，并给出最终被存在系统表中的存储计划。而批处理的T