kf_panda

要想优化一条 Query，我们就需要清楚的知道这条 Query 的性能瓶颈到底在哪里，是消耗的 CPU计算太多，还是需要的的 IO 操作太多？要想能够清楚的了解这些信息，在 MySQL 5.0 和 MySQL 5.1正式版中已经可以非常容易做到了，那就是通过 Query Profiler 功能。MySQL 的 Query Profiler 是一个使用非常方便的 Query 诊断分析工具，通

一般而言，我们在processlist结果中如果经常能看到某些SQL的话，至少可以说明这些SQL的频率很高，通常需要对这些SQL进行进一步优化。今天我们要说的是，在processlist中，看到哪些运行状态时要引起关注，主要有下面几个：状态建议copy to tmp table执行ALTER TABLE修改表结构时建议：放在凌晨执行或者采

优化mysql数据库时，经常有开发询问 count(1)和count(primary_key) VS count(*)的性能有何差异？看似简单的问题，估计会有很多人对此存在认知误区：1. 认为count(1) 和 count(primary_key) 比 count(*) 的性能好。2. count(column) 和 count(*) 效果是一样的。本文对上述两点做如下测试，测试

Descending indexing and loose index scan降序索引和减轻索引扫描Comments to my previous posts, especially this one by Gokhan inspired me to write a bit about descending indexes and about loose index scan, or

开发说他写了个SQL特别慢，让看看。select * from t_channel where id_ in(select distinct cdbh from sjkk_gcjl where jgsj>'2015-01-02 08:00:00' and jgsj<'2015-01-02 12:00:00');......30min+然后我查询内部SQL,只需要3s+mys

explain extended SELECT jlbh, kkbh, hphm, jgsj, clsdFROM sjkk_gcjl sWHERE 1 = 1AND hphm LIKE '%77'AND jgsj >= '2015-11-10 19:59:59'AND jgsj <= '2015-11-10 23:59:59'AND hpys = '2'ORDER B

EXPLAIN执行计划中有一列 key_len 用于表示本次查询中，所选择的索引长度有多少字节，通常我们可借此判断联合索引有多少列被选择了。在这里 key_len 大小的计算规则是：一般地，key_len 等于索引列类型字节长度，例如int类型为4-bytes，bigint为8-bytes；如果是字符串类型，还需要同时考虑字符集因素，例如：CHAR(30) UTF8则key_len至少

一、环境介绍mysql版本：5.5.41-tokudb-7.5.5表相关字段： `jlbh` varchar(31) NOT NULL,`hpys` varchar(1) NOT NULL,`jgsj` datetime NOT NULL,表相关索引：KEY `index10` (`hpys`,`jgsj`,`jlbh`,`hphm`,`kkbh`,`clpp`

今天开发说应用链接数据库比较慢，定位后发现是table_open_cache太小了引起的问题。如果你发现Opened_tables比较大并且一直再增大，很可能是table_open_cache设置太小了，导致每次链接数据库都要去打开表，这也会造成链接数据库比较慢。Open_tables : The number of tables that are open.Opened_table

官方的解释--skip-name-resolveDo not resolve host names when checking client connections. Use only IP addresses. If you use this option, allHost column values in the grant tables must be IP addresse

mysql接收到连接请求后，获得的是客户端的ip，为了更好的匹配mysql.user里的权限记录（某些是用hostname定义的）。如果mysql服务器设置了dns服务器，并且客户端ip在dns上并没有相应的hostname，那么这个过程很慢，导致连接等待。添加skip-name-resolve以后就跳过着一个过程了。

开源数据库MySQL比较容易碰到性能瓶颈，为此经常需要对MySQL数据库进行优化，而MySQL数据库优化需要运维DBA与相关开发共同参与，其中MySQL参数及服务器配置优化主要由运维DBA完成，开发则需要从数据类型优化，索引优化，SQL优化三个角度考虑MySQL数据库优化问题，本次分享将从开发角度，看如何实现MySQL数据库优化。本次分享大纲：一个例子

一 般情况下,DBA能从监控mysql的状态列表中查看出数据库的运行端倪，需要注意的是STATUS所表示的不同内容。且需要注意的是TIME字段表示的 意思。它表示的只是最后那个STAT状态持续的时间。这个时间是有可能忽大忽小的。而不是SQL开始执行到现在的时间。单位时间是秒。------------------------------------------------------------

语法：tbl_name [[AS] alias] [index_hint_list]index_hint_list: index_hint [, index_hint] ...index_hint: USE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}] ([index_list]) | IGNORE {INDEX|

对于带有列的函数计算的SQL，MySQL 是无法使用索引的，MySQL并没有Oracle中的函数索引，例如：SELECT *FROM table_1WHERE func_1(col_1) AND  func_2(col_2) = const_2ORDER BY func_3(col_3);在Oracle中，我们可以建里组合函数索引：CREATE INDE

explain语法有两种用法：1.EXPLAIN tbl_name2.EXPLAIN [EXTENDED] SELECT select_options为了更好的说明它，我们需要建两张表，下面的语句用于创建一张测试用的订单表：CREATE TABLE `t_order` (`order_id` int(10) unsigned NOT NULL AUTO_INCREMEN

重点是第二种用法，需要深入的了解。先看一个例子：mysql> explain select * from t_order; +----+-------------+---------+------+---------------+------+---------+------+--------+-------+ | id | select_type | table 

B树       即二叉搜索树：       1.所有非叶子结点至多拥有两个儿子（Left和Right）；       2.所有结点存储一个关键字；       3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；       如：              B树的搜索，从根结点开始，如果查询的关键字与结点的关键字相等，那么就命中；否则，

今天遇到一个问题，explain看到执行计划是没问题，但是执行起来速度奇慢，先看下问题吧。说明下环境，centos 6.5   32G内存  表数据量 8亿多mysql> explain select * from sjkk_gcjl where jgsj>='2010-01-20 00:00:00' AND jgsj<='2015-05-20 00:00:00' and hpys

开发说他们有个SQL特别慢，让我帮忙看看select id_ from t_channel where id_  not in (select distinct cdbh from sjkk_gcjl where jgsj>'2015-01-02 09:00:00' and jgsj<'2015-01-02 10:00:00' );......30分钟以上+----+-------

说明：物理读，指的是第一次查询，数据完全来自磁盘。            内存读，指的是查询时没有磁盘读，数据完全来自内存。第一个表的查询select jgsj,jlbh,hphm,clsd from sjkk_gcjl force index(index09) where jgsj>='2010-01-20 00:00:00' and jg

SHOW PROFILE [type [, type] ... ]    [FOR QUERY n]    [LIMIT row_count [OFFSET offset]]type：    ALL - displays all information    BLOCK IO - displays counts for block input and output op

覆盖索引：指的是查询SQL涉及的所有字段都包含在索引中。CREATE TABLE `sjkk_gcjl` ( `jlbh` varchar(50) NOT NULL COMMENT '记录编号', ....... KEY `index09` (`csys`,`jgsj`,`jlbh`,`hphm`,`clsd`), CLUSTERING KEY `index08` (`jgsj

优化前mysql> explain SELECT ROADMONITORID_,TRAFFICID_,PLATENUMBER_,PASSTIME_,SPEED_,PLATECOLOR_ FROM hadoop_firstinto -> WHERE PASSTIME_>='2015-01-23 13:59:16' AND PASSTIME_<='2015-10-23 13:59:16'

先做几个实验SQL1测试:select distinct hphm from sjkk_gcjlwhere jgsj>='2014-04-01 00:00:00' and jgsj<='2015-04-30 00:00:00' and hphm like '_BX_27_' and csys = 'E'limit 100;

今天开发说有个SQL特别慢，让优化下，我看了下是因为条件字段检索时的类型转换引起的索引不可用。 其中clpp字段和clnk字段都是字符串类型，他们当做数字类型使用。 原SQL: SELECT jlbh,xzqh,kkbh,cdbh,hphm,hpzl,hpys,jgsj,clsd,wzlx,cllx,csys,clpp,clzpp,clnk,facenum_,sunvisornum_,