tmp_table_size ---> 优化 MYSQL 经验总结

数据库连接突然增多到1000的问题

查看了一下,未有LOCK操作语句。

但是明显有好多copy to tmp table的SQL语句,这条语读的时间比较长,且这个表会被加读锁,相关表的update语句会被排进队列。如果多执行几次这样的copyt to tmp table 语句,会造成更多的语句被阻塞。

连接太多造成mysql处理慢。

copy to tmp talbe 语句产生的原因是查询需要Order By 或者Group By等需要用到结果集时,参数中设置的临时表的大小小于结果集的大小时,就会将该表放在磁盘上,这个时候在硬盘上的IO要比内销差很多。所耗费的时间也多很多。另外Mysql的另外一个参数max_heap_table_size比tmp_table_size小时,则系统会把max_heap_table_size的值作为最大的内存临时表的上限,大于这个时,改写硬盘。

我们的mysql这两个参数为:

tmp_table_size 33554432 (33.5M)

max_heap_table_size 16777216 (16.7M)

比较小。

建议增加到上百M。我们的内存应该够吧。

另外join_buffer_size(影响 表之间join性能的缓存)为131072 (131K)较小,可以增加一点。

[[email protected] ~]# vi /etc/my.cnf

[mysqld]

tmp_table_size=200M

mysql> show processlist; 
mysql> show columns from wp_posts; SQL 语句的第一个 LEFT JOIN ON 子句中: LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid  _mydata 的 userid 被参与了条件比较运算。为 _mydata 表根据字段 userid 建立了一个索引: mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )  增加 tmp_table_size 值。

mysql 的配置文件中,tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小,MySQL产生一个 The table tbl_name is full 形式的错误,如果你做很多高级 GROUP BY 查询,增加 tmp_table_size 值。 这是 mysql 官方关于此选项的解释:

tmp_table_size
This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory.

对 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的条件判断中用到的字段,应该根据其建立索引INDEX。
索引被用来快速找出在一个列上用一特定值的行。没有索引,MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大,花费时间越多。如果表对于查询的列有一个索引,MySQL能快速到达一个位置去搜寻到数据文件的中间,没有必要考虑所有数据。如果一个表有1000行,这比顺序读取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。
根据 mysql 的开发文档: 
索引 index 用于: 
快速找出匹配一个WHERE子句的行 
当执行联结(JOIN)时,从其他表检索行。 
对特定的索引列找出MAX()或MIN()值 
如果排序或分组在一个可用键的最左面前缀上进行(例如,ORDER BY key_part_1,key_part_2),排序或分组一个表。如果所有键值部分跟随DESC,键以倒序被读取。 
在一些情况中,一个查询能被优化来检索值,不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀,为了更快,值可以从索引树被检索出来。

假定你发出下列SELECT语句:

mysql> select * FROM tbl_name WHERE col1=val1 AND col2=val2;如果一个多列索引存在于col1和col2上,适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上,优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。

一般动态设置tmp_table_size的大小的时候,要使用:

set global tmp_table_size=64*1024*1024

而不是:

set global tmp_table_size=64M

否则就会出现错误:

#1232 - Incorrect argument type to variable ‘tmp_table_size‘

时间: 2024-10-12 04:04:48

tmp_table_size ---> 优化 MYSQL 经验总结的相关文章

MySQL 百万级分页优化(Mysql千万级快速分页)

以下分享一点我的经验 一般刚开始学SQL的时候,会这样写 : SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在数据达到百万级的时候,这样写会慢死 : SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 也许耗费几十秒 网上很多优化的方法是这样的: SELECT * FROM table WHERE id >= (SELECT id FROM table LIMIT 1000000, 1) LIM

优化MySQL服务器

7.5.1. 系统因素和启动参数的调节 我们从系统级因素开始,因为必须尽早地进行部分决策以获得较大性能.在其它情况下,快速浏览该节就足够了.但是,了解一下更改该层次的参数能够获得多少性能提高是很有意义的. 使用的操作系统很重要.为了更好地使用多CPU机器,应使用Solaris(因为其线程工作得很好)或Linux(因为2.4和以后的内核有很好的SMP支持).请注意默认情况旧的Linux内核有一个2GB的文件大小限制.如果有这样的一个内核并且需要文件大于2GB,应得到ext2文件系统的大文件支持(L

MySQL优化-MySQL体系结构

MySQL优化-MySQL体系结构 三层体系结构: 连接层 SQL层 存储层 关于timeout 通过jdbc等程序连接的是非交互会话. 通过mysql cli客户端连接的是交互会话. wait_timeout,关闭非交互连接(程序端)之前等待的秒数.默认8h. interactive_timeout,关闭交互式连接(客户端)前等待的秒数.默认8h. 本节小结: 5.7开始,支持密码过期机制. 8.0开始,支持更多密码安全机制,更安全的MySQL 8.0之全新密码策略. 一些LB应用会疯狂探测数

优化MYSQL数据库的方法

1.选取最适用的字段属性 尽可能减少定义字段长度,尽量把字段设置NOT NULL,例如'省份,性别',最好设置为ENUM 2.使用连接(JOIN)来代替子查询:  a.删除没有任何订单客户 ELETE FROM customerinfo WHERE customerid NOT in(SELECT customerid FROM orderinfo) b.提取所有没有订单客户 SELECT FROM customerinfo WHERE customerid NOT in(SELECT cust

优化MySQL,还是使用缓存?读一篇文章有感

今天我想对一个Greenfield项目上可以采用的各种性能优化策略作个对比.换言之,该项目没有之前决策强加给它的各种约束限制,也还没有被优化过. 具体来说,我想比较的两种优化策略是优化MySQL和缓存.提前指出,这些优化是正交的,唯一让你选择其中一者而不是另一者的原因是他们都耗费了资源,即开发时间. 优化MySQL 优化MySQL时,一般会先查看发送给mysql的查询语句,然后运行explain命令.稍加审查后很常见的做法是增加索引或者对模式做一些调整. 优点 1.一个经过优化的查询对于所有使用

使用TCMalloc 优化MySQL

使用TCMalloc 优化MySQLhttp://download.savannah.gnu.org/releases/libunwind/libunwind-1.1.tar.gz http://gperftools.googlecode.com/files/gperftools-2.1.tar.gz 参照MySQL管理之道 19页进行安装tar -xf libunwind-1.1.tar.gzcd libunwind-1.1CFLAGS=-fPIC ./configure --enable-s

MYSQL之性能优化 ----MySQL性能优化必备25条

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我 们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能.这里,我们不会讲过 多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库.希望下面的这些优化技巧对你有用. 1. 为查询缓存优化你的查询 大多数的MySQL服务器都开启了查询缓存.这是提高性最有效的方法之一,而且这是被

性能优化——mysql数据库

一 mysql常用命令 1. 打开日志 1) show global variables like "%genera%"; 2)set global general_log=on; 3)set global general_log=off; 2. mysql如果开了set autocommit=0,那么所有的语句一定是在一个事务里 3. show engine innodb status 1) http://imysql.cn/2008_05_22_walk_through_show_

每天进步一点点————优化MySQL SERVER(1)

1.   优化MySQL SERVER 7组后台进程 masterthread:主要负责将脏缓存页刷新到数据文件,执行purge操作,触发检查点,合并插入缓冲区等. insertbuffer thread:主要负责插入缓冲区的合并操作. readthread:负责数据库读取操作,可配置多个线程 writethread:负责数据库写操作,可配置多个线程. logthread:用于将重做日志刷新到logfile中. purgethread:MySQL5.5之后用于单独的purge thread 执行