sql优化

我们通常衡量一个Web系统的吞吐率的指标是QPS（Query Per Second，每秒处理请求数），解决每秒数万次的高并发场景，这个指标非常关键。举个例子，我们假设处理一个业务请求平均响应时间为100ms，同时，系统内有20台Apache的Web服务器，配置MaxClients为500个（表示Apache的最大连接数目）。 那么，我们的Web系统的理论峰值QPS为（理想化的计算方式）： 20*500/0.1 = 100000 （10万QPS） 咦？我们的系统似乎很强大，1秒钟可以处理完10万的请求，5w/s的秒杀似乎是“纸老虎”哈。实际情况，当然没有这么理想。在高并发的实际场景下，机器都处于高负载的状态，在这个时候平均响应时间会被大大增加。 普通的一个p4的服务器每天最多能支持大约10万左右的IP，如果访问量超过10W那么需要专用的服务器才能解决，如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度 有：网络-硬盘读写速度-内存大小-cpu处理速度。 就Web服务器而言，Apache打开了越多的连接进程，CPU需要处理的上下文切换也越多，额外增加了CPU的消耗，然后就直接导致平均响应时间增加。因此上述的MaxClient数目，要根据CPU、内存等硬件因素综合考虑，绝对不是越多越好。可以通过Apache自带的abench来测试一下，取一个合适的值。然后

zabbix的监控主机数量将近300，且运行了一年时间了，最近zabbix server服务监控历史数据等服务不断自身告警、查询性能也变得很低 关于历史数据的两个参数，在zabbix server的配置文件中 可以选择关闭housekeeper禁止自动定期清除历史记录数据，因为对于大数据的删除会直接影响zabbix的性能、或者调整相应参数 HousekeepingFrequency 取值范围：0-24 默认值：1 说明：housekeep执行频率，默认每小时回去删除一些过期数据。如果server重启，那么30分钟之后才执行一次，接下来，每隔一小时在执行一次。 MaxHousekeeperDelete 取值范围： 0-1000000 默认值：5000 housekeeping一次删除的数据不能大于MaxHousekeeperDelete 数据库优化 一、设置独立表空间（innodb_file_per_table=1） # 5.6版本以上自动开启 以上版本跳过这一段 1、清空history数据 [root@Zabbix-Server ~]# mysql -u zabbix -p MariaDB [(none)]> use zabbix; Reading table information for completion of table and column names You can

SET NOCOUNT 使返回的结果中不包含有关受 Transact-SQL 语句影响的行数的信息。 语法 SET NOCOUNT { ON | OFF } 注释 当 SET NOCOUNT 为 ON 时，不返回计数（表示受 Transact-SQL 语句影响的行数）。当 SET NOCOUNT 为 OFF 时，返回计数。 即使当 SET NOCOUNT 为 ON 时，也更新 @@ROWCOUNT 函数。 当 SET NOCOUNT 为 ON 时，将不给客户端发送存储过程中的每个语句的 DONE_IN_PROC 信息。当使用 Microsoft SQL Server 提供的实用工具执行查询时，在 Transact-SQL 语句（如 SELECT、INSERT、UPDATE 和 DELETE）结束时将不会在查询结果中显示"nn rows affected"。 如果存储过程中包含的一些语句并不返回许多实际的数据，则该设置由于大量减少了网络流量，因此可显著提高性能。 SET NOCOUNT 设置是在执行或运行时设置，而不是在分析时设置。 权限 SET NOCOUNT 权限默认授予所有用户。 结论：我们应该在存储过程的头部加上SET NOCOUNT ON 这样的话，在退出存储过程的时候加上 SET NOCOUNT OFF这样的话，以达到优化存储过程的目的。 来源： https://www

目录 1）连接请求的变量 1、max_connections 2、back_log 3、wait_timeout和interative_timeout 2）缓冲区变量 4、key_buffer_size 5、query_cache_size（查询缓存简称QC) 6、max_connect_errors： 7、sort_buffer_size： 8、max_allowed_packet=32M 9、join_buffer_size=2M 10、thread_cache_size=300 3）配置Innodb的几个变量 11、innodb_buffer_pool_size 12、innodb_flush_log_at_trx_commit 13、innodb_thread_concurrency=0 14、innodb_log_buffer_size 15、innodb_log_file_size=50M 16、innodb_log_files_in_group=3 17、read_buffer_size=1M 18、read_rnd_buffer_size=16M 19、bulk_insert_buffer_size=64M 20、binary log 参数汇总： MySQL参数优化对于不同的网站，及其在线量，访问量，帖子数量，网络情况，以及机器硬件配置都有关系，优化不可能一次性完成

Druid是什么？有什么作用？ Druid首先是一个数据库连接池，但它不仅仅是一个数据库连接池，它还包含一个ProxyDriver，一系列内置的JDBC组件库，一个SQL Parser。 Druid的项目背景？目前的项目团队情况？开源目的？ 2010年开始，我负责设计一个叫做Dragoon的监控系统，需要一些监控组件，监控应用程序的运行情况，包括Web URI、Spring、JDBC等。为了监控SQL执行情况，我做了一个Filter-Chain模式的ProxyDriver，缺省提供StatFilter。当时我还做了一个SQL Parser。老板说，不如我们来一个更大的计划，把连接池、SQL Parser、Proxy Driver合起来做一个项目，命名为Druid，于是Druid就诞生了。 2011年2月春节期间，我完成了连接池（DruidDataSource）的第一个版本，4月开始在生产环境测试，2012年第一季度开始大规模实施。 提交过代码的开发者有5个人，主要代码是我维护，有一人专门负责内部实施。 通过开源，希望有更多使用场景，更多的反馈，更多人参与其中，共同打造最好的数据库连接池。 Druid支持哪些数据库？ Druid支持所有JDBC兼容的数据库，包括Oracle、MySql、Derby、Postgresql、SQL Server、H2等等。

许多有经验的数据库开发或者DBA都曾经头痛于并行查询计划，尤其在较老版本的数据库中（如sqlserver2000、oracle 7、mysql等）。但是随着硬件的提升，尤其是多核处理器的提升，并行处理成为了一个提高大数据处理的高效方案尤其针对OLAP的数据处理起到了很好的作用。 充分高效地利用并行查询需要对调度、查询优化和引擎工作等有一个比较好的了解，但是针对一般场景的应用我们只需要如何常规使用即可，这里也就不深入描述了，感兴趣可以一起讨论。 那么这里我就简单介绍下SQLServer中并行的应用？ 什么是并行? 我们从小就听说过“人多力量大”、“人多好办事”等，其思想核心就是把一个任务分给许多人，这样每个人只需要做很少的事情就能完成整个任务。更重要的是，如果额外的人专门负责分配工作，那么任务的完成时间就可以大幅减少了。 数糖豆 设想你正面对一个装满各式各样糖豆的罐子，并且要求书有多少个。假设你能平均每秒数出五个，需要大于十分钟才能数完这个盒子里的3027个糖豆。 如果你有四个朋友帮助你去做这个任务。你就有了多种策略来安排这个数糖豆任务，那让我们模仿SQLServer 将会采取的策略来完成这个任务。你和4个朋友围坐在一个桌子四周，糖果盒在中心，用勺子从盒子中拿出糖豆分给大家去计数。每个朋友还有一个笔和纸去记录数完的糖豆的而数量。 一旦一个人输完了并且盒子空了，他们就把自己的纸给你

本文针对目前最新版9.5.1，若非说明，文中所说文档即指官方文档。本人刚接触PostgreSQL不久，文中不免错漏，请大家指正；随着了解深入，本文[可能]会不定期更新补足。 JSON PostgreSQL支持Json格式数据，有两种类型：json和jsonb。两者在效率上有所区别，而这是因为jsonb存储的是格式化后的二进制数据，所以在写入时，json类型比较快，而在检索时（注意这里说的检索不是简单的读取整个数据，而是比如检索json数据中某个键的值的场景），jsonb效率较高。一般情况下，使用jsonb就可以了。json数据是为了弥补关系型数据在伸缩性扩展性上的不足，但是文档也说了，不能啥都往里放，要考虑数据原子性和数据大小。 json类型可以作包含判断和是否存在的判断（containment or existence），表示符号分别为@>和?（以及其它一些变种）。对于这两种牵涉到多个键和元素的判断场景，json类型比下面要讲的arrays更适合，因为其对查询有内在的优化机制，而array只是单纯的线性查找。 若json列需要经常检索，那么可以在其上建立GIN索引，jsonb支持两种特有的GIN索引jsonb_ops和jsonb_path_ops。创建的语法如下： CREATE INDEX idxgin ON api USING GIN (jdoc); CREATE INDEX

1、查询是否锁表 show OPEN TABLES where In_use > 0; 查询到相对应的进程 === 然后 kill id 2、查询进程 show processlist 补充： 查看正在锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 查看等待锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 1 show processlist; SHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程（也就是，与您正在使用的MySQL账户相关的线程）。如果有线程在update或者insert 某个表，此时进程的status为updating 或者 sending data。 如果您得到“too many connections”错误信息，并且想要了解正在发生的情况，本语句是非常有用的。MySQL保留一个额外的连接，让拥有SUPER权限的账户使用，以确保管理员能够随时连接和检查系统（假设您没有把此权限给予所有的用户）。 Status 含义 Checking table 正在检查数据表（这是自动的）。 Closing

(一)id列： (1)、id 相同执行顺序由上到下 mysql> explain -> SELECT*FROM tb_order tb1 -> LEFT JOIN tb_product tb2 ON tb1.tb_product_id = tb2.id -> LEFT JOIN tb_user tb3 ON tb1.tb_user_id = tb3.id; +----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+ | 1 | SIMPLE | tb1 | ALL | NULL | NULL | NULL | NULL | 1 | NULL | | 1 | SIMPLE | tb2 | eq_ref |

Explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，Explain可以用来查看 SQL 语句的执行效 果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。 Explain语法：explain select … from … [where ...] 例如：explain select * from news; 输出： +----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+-------------------+---------+---------+-------+------+-------+ 下面对各个属性进行了解： 1、id：这是SELECT的查询序列号 2、select_type：select_type就是select的类型，可以有以下几种： SIMPLE：简单SELECT(不使用UNION或子查询等) PRIMARY