主页 |  MySQL 消息 |  常见问题 |  Feeds |  发布 |  回复 |  归档 |  Aggregate feed RSS 2.0 中文 English Deutsch Español Français Italiano 日本語 Русский Português
表示 进入内容 130564 下一步 30 较早的记录
[MySQL FAQ]系列 — 5.6版本GTID复制异常处理一例
+0 Vote Up -0Vote Down

昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例,MASTER上的任何操作都无法在SLAVE上应用,SLAVE的RELAY LOG里有记录,但SLAVE的BINLOG却找不到蛛丝马迹。由于开启了GTID,所以排查起来也简单,只需要在SLAVE上把RELAY LOG和BINLOG分别解析成文本文件,再直接搜索MASTER的UUID,就能找到SLAVE上是否应用了MASTER复制过来的事务。 排查过程中,曾经一度怀疑是因为设置了BINLOG-DO或者IGNORE规则,或者设置了REPLICATION-DO或IGNORE规则,甚至是GTID的严重BUG,但都没发现端倪。直到从 SHOW SLAVE STATUS 里发现下面这个信息:

[yejr@imysql.com]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
...
  [获取更多。。]
[MySQL优化案例]系列 — 分页优化
+0 Vote Up -0Vote Down

通常,我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询。例如下面这个SQL:

SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10;

或者像下面这个不带任何条件的分页SQL:

SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10;

一般而言,分页SQL的耗时随着 start 值的增加而急剧增加,我们来看下面这2个不同起始值的分页SQL执行耗时:

yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10;
…

10 rows in set (0.05 sec)


yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=6 ORDER BY id DESC LIMIT 935500, 10;
…

10 rows in set (2.39 sec)
  [获取更多。。]
MySQL的secure_auth錯誤
+0 Vote Up -0Vote Down
Original post: http://anothermysqldba.blogspot.com/2014/07/mysql-secureauth-error.html

我以前處理的secure_auth錯誤時,在此它阻止複製的博客文章 。 

不過,我想通通過MySQL的客戶端連接時,我會把這個博客帖子更一般的修復。 這是MySQL 5.6之前的服務器。 

所以,如果你得到一個secure_auth錯誤,當連接到MySQL下面的步驟應該清除此錯誤。 







  [获取更多。。]
TIPS:MySQL 改库名操作
+0 Vote Up -0Vote Down

作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MySQL在5.1引入了一个rename database操作,但在MySQL5.1.23后又不支持这个命令。可以说是一个实验性的功能,没有在生产中支持过(mysql-5.1 release在mysql-5.1.30),那么生产中我们有时为了追求完美需要改一下库名。怎么操作呢?
这里提供一个变通的方法。
1. 创建出新库名:

mysql>create database db_v2;
  • 生成rename语句,从olddb里迁移,我这里olddb里sbtest;
  • mysql>select concat("rename table ",table_schema,".",table_name," to db_v2.",table_name,";") into outfile '/tmp/rename_to_db_v2.sql' from information_schema.tables where table_schema='sbtest';
    


      [获取更多。。]
    MySQL中,Ubuntu的:: mysqld不能有訪問權限
    +0 Vote Up -0Vote Down
    Original post: http://anothermysqldba.blogspot.com/2014/07/mysql-ubuntu-mysqld-does-not-have.html
    所以今天我正好需要從備份中恢復一個MySQL數據庫,所以我可以恢復一些表。 雖然我離開了他的生產數據庫通過端口3306上運行,我設置的備份通過端​​口3307。 

    然而,當我試圖通過在mysql_restore目錄中的3307端口上啟動另一個版本,但我遇到了一些錯誤.... 


    /usr/bin/mysqld_safe --defaults-file=/etc/my_3307.cnf 

    [Warning] Can't create test file /var/lib/mysql_restore/localhost.lower-test 
    [Warning] Can't create test file /var/lib/mysql_restore/localhost.lower-test 
    Can't find file: './mysql/plugin.frm' (errno:









      [获取更多。。]
    MySQL Fabric - 為您的應用系統提供高可用、高擴充性的資料庫
    Employee +0 Vote Up -0Vote Down
    MySQL Fabric - 為您的應用系統提供高可用、高擴充性的資料庫

    Oracle在今年5月初推出了一套為各方寄以厚望的在MySQL產品 – MySQL Fabric,單從字面上似乎不太能看出它是啥咪碗糕,但是由名稱上還是有跡可循的,”Fabric”是"織"或"織品",這意味著它是用來"織"起"一片”MySQL資料庫。MySQL Fabric是一套資料庫伺服器場(Database Server Farm)的架構管理系統。
    MySQL Fabric是什麼? MySQL Fabric 能 『組織』多個MySQL資料庫,使應用系統能將大於幾TB的表分散到多個資料庫 – 做Data


      [获取更多。。]
    mongodb性能基准测试工具ycsb
    +0 Vote Up -0Vote Down

    mongodb性能基准测试工具ycsb

    熟悉mysql的同学一定都听说过tpcc-mysql这个mysql性能测试的工具,与其类似,nosql界也有一个性能基准测试工具ycsb。Yahoo! Cloud Serving Benchmark。

    ycsb需要java环境,需要maven。

    mvn clean package的时候可能会报错…在pom.xml中把不需要的测试对象删除即可,如infinispan,cassandra,hbase之类的。

    在workloads目录中,ycsb提供了6种workload,比如50%读50%写,95%读5%写等等,每次只能测试某一种workload。

    测试的过程分为load 与 run 二个过程,load即为把测试数据写入db,run即为 run workload。

    ycsb支持的参数并不多,这样很好。

    ./bin/ycsb load mongodb -s -P workloads/workloadH -threads 100 >out

    ./bin/ycsb run mongodb -s -P workloads/workloadH -threads 200 >out

      [获取更多。。]
    [MySQL FAQ]系列 — 大数据量时如何部署MySQL Replication从库
    +0 Vote Up -0Vote Down

    我们在部署MySQL Replication从库时,通常是一开始就做好一个从库,然后随着业务的变化,数据也逐渐复制到从服务器。

    但是,如果我们想对一个已经上线较久,有这大数据量的数据库部署复制从库时,应该怎么处理比较合适呢?

    本文以我近期所做Zabbix数据库部署MySQL Replication从库为例,向大家呈现一种新的复制部署方式。由于Zabbix历史数据非常多,在转TokuDB之前的InnoDB引擎时,已经接近700G,转成TokuDB后,还有300多G,而且主要集中在trends_uint、history_uint等几个大表上。做一次全量备份后再恢复耗时太久,怕对主库写入影响太大,因此才有了本文的分享。

      [获取更多。。]
    Antelope 和Barracuda区别
    +0 Vote Up -0Vote Down

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

    Antelope是innodb-base的文件格式, Barracude是innodb-plugin后引入的文件格式,同时Barracude也支持Antelope文件格式。两者区别在于:

    文件格式 支持行格式 特性 Antelope

    (Innodb-base) ROW_FORMAT=COMPACT

    ROW_FORMAT=REDUNDANT

    Compact和redumdant的区别在就是在于首部的存存内容区别。

    compact的存储格式为首部为一个非NULL的变长字段长度列表

    redundant的存储格式为首部是一个字段长度偏移列表(每个字段占用的字节长度及其相应的位移)。

      [获取更多。。]
    [MySQL优化案例]系列 — RAND()优化
    +0 Vote Up -0Vote Down

    众所周知,在MySQL中,如果直接 ORDER BY RAND() 的话,效率非常差,因为会多次执行。事实上,如果等值查询也是用 RAND() 的话也如此,我们先来看看下面这几个SQL的不同执行计划和执行耗时。
    首先,看下建表DDL,这是一个没有显式自增主键的InnoDB表:

    [yejr@imysql]> show create table t_innodb_random\G
    *************************** 1. row ***************************
    Table: t_innodb_random
    Create Table: CREATE TABLE `t_innodb_random` (
    `id` int(10) unsigned NOT NULL,
    `user` varchar(64) NOT NULL DEFAULT '',
    KEY `idx_id` (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1
    

    往这个表里灌入一些测试数据,至少10万以上, id 字段也是乱序的。

    [yejr@imysql]> select count(*) from t_innodb_random\G
    *************************** 1. row

      [获取更多。。]
    Percona Thread Pool性能基准测试
    +0 Vote Up -0Vote Down

    MySQL从5.5.16开始,在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。后来MariaDB也实现了这一功能,Percona也跟进实现了。从这几天对Percona 5.6.16版本做了下thread pool对比测试,试图找到较为合适的配置参数。

    下面是几个测试模式对比:

    模式 配置参数 Percona 5.6.16-nothp 未开启 thread pool 模式 CASE0-thp(128)-oversub(16)-max(2048) thread_handling = pool-of-threads
    thread_pool_size = 128
    thread_pool_oversubscribe = 16
    thread_pool_max_threads = 2048 CASE1-thp(default) thread_handling = pool-of-threads
    其他默认设置 CASE2-thp(default)-oversub(10) thread_handling = pool-of-threads
    thread_pool_oversubscribe = 10
    其他默认设置 CASE3-thp(default)-oversub(10)-max(10000) thread_handling = pool-of-threads







      [获取更多。。]
    Mongo php如何证明只读查询发生在secondary server
    +0 Vote Up -0Vote Down

    Mongo php如何证明只读查询发生在secondary server

    虽然mongo官方并不推荐在replica set的secondary server上进行查询操作,但是作为一个mysql的老用户,表示一定要这样用。

    继续昨天1主2从1 arbiter的架构。
    从ubuntu:27020;rs0;
    主ubuntu:27021;rs0;
    从ubuntu:27022;rs0;
    A ubuntu:27023;rs0;

    php脚本在建立连接的时候,应该连接哪个mongo服务器呢?

    答案是主从A都随意。 其实应该是把这四台都写上才对。

    当然在这四台机器前面再加一个proxy就更好了。

    接下来的问题,就是如何让find()等只读操作route到从服务器了,很容易想到slaveOk()吧?

    http://kr1.php.net/manual/en/mongodb.setslaveokay.php

    可惜的是, 这个method 被DEPRECATED 了。
    替代的办法就是:






      [获取更多。。]
    Mongodb Replica Set Deployment
    +0 Vote Up -0Vote Down

    Mongodb Replica Set Deployment

    在一台虚拟机里面安装了三个mongod实例,一主二从,另外还安装了一个arbiter。

    创建数据总目录
    root@ubuntu:/# mkdir /data/mongodb -p
    创建日志目录
    root@ubuntu:/# mkdir /data/mongodb_log -p
     
    创建三个mongod实例的数据目录
    root@ubuntu:/# cd /data/mongodb
    root@ubuntu:/data/mongodb# mkdir rs0-0
    root@ubuntu:/data/mongodb# mkdir rs0-1
    root@ubuntu:/data/mongodb# mkdir rs0-2
     
     
     
    启动三个mongod.
    replSet名为 rs0
     
    mongod --port 27020 --dbpath /data/mongodb/rs0-0 --logpath /data/mongodb_log/rs0-0.log --replSet rs0 --logappend &
    mongod --port 27021 --dbpath /data/mongodb/rs0-1 --logpath /data/mongodb_log/rs0-1.log --replSet rs0 --logappend &
    mongod --port 27022 --dbpath /data/mongodb/rs0-2 --logpath /data/mongodb_log/rs0-2.log --replSet rs0 --logappend &
     
     
     
      [获取更多。。]
    Comment on mysql5.6 alter table 与 Waiting for table metadata lock by yuanyuan
    +0 Vote Up -0Vote Down

    SELECT sleep(100) FROM t
    这个是每行记录都会sleep 100s,所以整个的执行时间 100*num(记录行数)

    MySQL的表錯誤1064
    +0 Vote Up -0Vote Down
    Original post : http://anothermysqldba.blogspot.com/2014/06/mysql-table-error-1064.html

    所以,我碰到一個奇怪的局面今天就來了。 

    我有一個使用PHP $ _COOKIE ['PHPSESSID']的值創建內存表的系統。 

    一旦有些工作已經完成它,然後刪除表。 

    兩個示例表下面是我的榜樣。 


    @@VERSION: 5.6.19-log 
    CREATE TABLE `f7a7a8d3a7ba75b5eb1712864c9b27eb` ( 
    -> `id` int(11) NOT NULL AUTO_INCREMENT, 
    -> PRIMARY KEY (`id`) 
    -> ) ENGINE=MEMORY; 

    CREATE TABLE `8865e52c7e1bea515e7156f240729275` ( 
    -> `id` int(11) NOT NULL AUTO_INCREMENT, 
    -> PRIMARY KEY (`id`) 
    -> )



















      [获取更多。。]
    迁移Zabbix数据库到TokuDB
    +0 Vote Up -0Vote Down

    背景介绍

    线上的Zabbix数据库有几个大表数据量疯狂增长,单表已经超过500G,而且在早期也没做成分区表,后期维护非常麻烦。比如,想删除过期的历史数据,在原先的模式下,history、history_uint等几个大表是用 (itemid, clock) 两个字段做的联合主键,只用 clock 字段检索效率非常差。

    TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点是高压缩比,高 INSERT 性能,支持大多数在线修改索引、添加字段,特别适合像 Zabbix 这种高 INSERT,少 UPDATE 的应用场景。

    迁移准备

    欲使用 TokuDB 引擎,服务层可以选择和 MariaDB ,也可以选择 Percona ,鉴于我以往使用 Percona 的较多,因此本次也选择使用 Percona 版本集成 TokuDB 引擎。

      [获取更多。。]
    [MySQL FAQ]系列 — mysqldump加-w参数备份
    +0 Vote Up -0Vote Down

    我们在用mysqldump备份数据时,有个选项是 –where / -w,可以指定备份条件,这个选项的解释是:

    -w, --where=name    Dump only selected records. Quotes are mandatory
    

    我们可以做个测试,例如:

    mysqldump --single-transaction -w ' id < 10000 ' mydb mytable > mydump.sql
    

    这时候就可以备份出mytable表中 id< 10000 的所有记录了。假设我们还想加一个时间范围条件,例如:

    mysqldump --single-transaction -w " id < 10000 and logintime < unix_timestamp('2014-06-01')" mydb mytable > mydump.sql
    

    在这里,一定注意单引号和双引号问题,避免出现这种情况:

    mysqldump --single-transaction -w ' id < 10000 and logintime < unix_timestamp('2014-06-01') ' mydb mytable > mydump.sql
    
      [获取更多。。]
    简单的验证码识别
    +0 Vote Up -0Vote Down

    简单的验证码识别

    首先来看这张经典的验证码:

    人脑可以主动过滤掉杂乱的背景,在识别的过程中也可以忽略掉那条很长的曲线,然后非常轻松地识别出四个字符:TXSb。

    计算机拿到这张图,它就2了。。。一个JPG文件,对计算机来说就是一堆2进制数据。还好JPG有自身的数据结构,可以按照相应算法读取到图片中每一个点的颜色。也就如此而已了。

    颜色分布在 0×000000 ~ 0xFFFFFF(0xRGB), 数目众多。为了把事情简化,可以先对图片进行灰度化处理,即把原有颜色转化为灰色。


      [获取更多。。]
    MySQL的隨機整數
    +0 Vote Up -0Vote Down
    Original post: http://anothermysqldba.blogspot.com/2014/06/mysql-random-integers.html

    這是不以任何手段的一項新功能,但它是一個問題,我也碰巧看到彈出飄飛。 所以,一個簡單的例子是下面的。 

    到MySQL中生成一個隨機整數您可以使用地板和蘭德功能。 MySQL手冊此文件在這裡:http://dev.mysql.com/doc/refman/5.5/en/mathematical-functions.html#function_rand 

    “ 





      [获取更多。。]
    第一届8P啤酒节开幕
    +0 Vote Up -0Vote Down

    第一届8P啤酒节于2014年6月13日在帝都朝阳区开幕。

          8P啤酒节举办期间恰逢(故意的)巴西世界杯,啤酒节将足球与啤酒进行有机结合,为参节游客详尽介绍历届世界杯主办国、冠军球队以及他们所钟爱的啤酒。另外游客还可以在这里了解啤酒文化、啤酒历史以及足球和啤酒之间的各种趣闻。 
         

          近日从8P啤酒节组委会获悉,截至目前,有十余家顶级啤酒企业参节,如雪花啤酒、哈尔滨啤酒、百威啤酒、燕京啤酒、喜力啤酒、虎牌啤酒、凯撒啤酒,蓝带啤酒,青岛啤酒等知名啤酒企业。
            

            赞助商:圆通快递,青岛啤酒天猫旗舰店,8瓶啤酒俱乐部,新东方一对一,京客隆,百度云资源你懂的。




      [获取更多。。]
    安裝Percona的XtraDB集群
    +0 Vote Up -0Vote Down
    Original post: http://anothermysqldba.blogspot.com/2014/06/installing-percona-xtradb-cluster.html

    所以當然Percona的都有解釋的過程文檔。 這個博客的目的是進入了更多的細節,希望能幫助別人。 

    超鏈接的點評: 





      [获取更多。。]
    MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16压测瓶颈分析
    +0 Vote Up -0Vote Down

    之前我进行了MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16对比基准TPCC压测,从测试结果可以看到在高并发(并发1920线程)模式下,MariaDB的相对优势,也看到了在一般并发场景(并发64线程)模式下,MariaDB拥有绝对优势。

    今天我们就来看看这两种模式下,系统负载等性能指标表现,以及各自的瓶颈在哪里,也就能知道为何有这么大差异了。

    首先,我们看下并发64线程的对比图表:

      [获取更多。。]
    分享我的测试结果模板
    +0 Vote Up -0Vote Down

    我经常会进行一些基准测试工作,测试结果需要进行对比,一般测试结果采用图表展示的方式再阐述结论最为通俗易懂。

    本次分享下我平时用excel来生成图表的方法:

    一、数据收集、初始化

    1、构建一个excel表格

    2、纵向表示多种对比的测试模式

    3、横向表示各个测试模式在不同条件下的测试结果值

    二、生成对比图表

    1、选中excel表格各行各列

    2、选择功能菜单中的“插入”=>“推荐的图表”(office 2013模式下是这样,其他版本可能有不同名称)

    3、选择合适的图表模板,确认即可生成多条曲线对比图

      [获取更多。。]
    MySQL 5.6.17/Percona5.6.16/MariaDB 10.0.11/OneSQL 5.6.16 TpmC测试
    +0 Vote Up -0Vote Down

    近日花了点时间对几个分支版本进行对比测试,包括了:MySQL 5.6.17、Percona5.6.16、MariaDB 10.0.11、OneSQL 5.6.16。

    1、测试基准 测试工具: tpcc-mysql 测试Warehouse数: 10/100 warmup time: 120s run time: 1800s 并发线程数: 64 ~ 1920 2、测试环境: OS:RHEL 6.4 内核:2.6.32-358.el6.x86_64 磁盘:INTEL SSDSC2BA800G3 3、MySQL配置: innodb_buffer_pool_size = 26G sync_binlog = 0 innodb_flush_log_at_trx_commit = 1/3 #OneSQL设置为3,其他设置为1 tcc_max_transaction_concurrency = 64 #OneSQL设置

    tpcc-mysql测试脚本可以参见我以前的一个分享:分享:服务器基准测试 或者 

      [获取更多。。]
    [MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题
    +0 Vote Up -0Vote Down

    收到一个mysql服务器负载告警,上去一看,load average都飙到280多了,用top一看,CPU跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了。

    看下processlist以及slow query情况,发现有一个SQL经常出现,执行计划中的扫描记录数看着还可以,单次执行耗时为0.07s,还不算太大。乍一看,可能不是它引发的,但出现频率实在太高,而且执行计划看起来也不够完美:

    mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = ’81′\G

    *************************** 1. row ***************************
    id: 1
    select_type: SIMPLE
    table: b
    type: index_merge
    possible_keys:




      [获取更多。。]
    一个mysqldump导出失败的案例分析
    +0 Vote Up -0Vote Down

     背景

    MySQL全量逻辑备份恢复最基础的方法,就是mysqldump生成文本,再通过source 命令直接导入。一般用于实例迁移或者版本升级。

    这里说明最近碰到的一个失败例子。

    描述

    这个例子可以简要复现如下,在源库上执行如下操作:

    use mydb;

    create table t1 (id int);

    create view v1 as select * from t1;

    drop table t1;

     

    之后执行 mysqldump mydb,发现mysqldump中途退出。简化后出错原因很明显,就是视图v1对应的表t1已经不存在,这个视图本身非法。

    这个错误很危险,因为如果没有捕获这个错误,直接认为mysqldump执行完成,并将生成的结果应用于目标库,则会导致数据丢失!

    其实这个问题并不像看起来那么简单。

      [获取更多。。]
    MySQL 聚集UDF,计算列表中的奇数总和
    +0 Vote Up -0Vote Down

     

     技痒之作 -__-

     

     CREATE AGGREGATE FUNCTION oddsum returns INTEGER SONAME "udf_oddsum.so";

    CREATE TABLE `v1` (

      `c` int(11) DEFAULT NULL,

      `id` int(11) NOT NULL,

      PRIMARY KEY (`id`)

    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

    insert into v1 values(1,0), (3,2), (4,4);

     

     select sum(c),oddsum(c) from v1;

    +--------+-----------+

    | sum(c) | oddsum(c) |

    +--------+-----------+

    |      8 |         4 |

    +--------+-----------+

      

     

    #ifdef HAVE_STDLIB_H
    #include <stdlib.h>
    #endif
    #ifdef HAVE_STRING_H
    #include <string.h>
    #endif
    #ifdef HAVE_STRINGS_H
    #include <strings.h>
    #endif
    
    #include <ctype.h>
    #include <my_global.h>
    #include <my_sys.h>
    #include <mysql.h>
    
    my_bool oddsum_init(UDF_INIT
      [获取更多。。]
    autocommit=0引起的业务hang住
    +0 Vote Up -0Vote Down

    背景

    有用户报告一个普通的select 语句被hang住了,执行超时。查明之后发现是autocommit使用不当导致。
    这里将case简化,说明复现步骤及原因。
    

    复现

    session1 建表并插入数据:
    
    create table if not exists t(id int primary key, c int);
    set autocommit=0;
    insert into t values(1,1);
    insert into t values(2,2);
    insert into t values(3,3);
    commit;
    select count(*) from t;
    
    这个执行流程的目的很直观,建表、插入数据、查询结果。貌似没有问题。
    
    维持session1不断,新建一个连接session2,执行 create table if not exists t(id int primary key, c int);
    此时该语句处于等待状态.
    
    再新建一个连接session3, 执行select count(*) from t; 该语句处于等待状态.
    
    于是从业务上看就是一个select 语句被hang住。
    
      [获取更多。。]
    cpuspeed和irqbalance服务器的两大性能杀手
    +0 Vote Up -0Vote Down

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

    最近在一个性能测试中遇到机器的CPU频率不对。查了一下原来是irqbalance和cpuspeed搞出来问题。
    irqbalance 理论上:
    启用 irqbalance 服务,既可以提升性能,又可以降低能耗。
    irqbalance 用于优化中断分配,它会自动收集系统数据以分析使用模式,并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。
    处于 Performance mode 时,irqbalance 会将中断尽可能均匀地分发给各个 CPU core,以充分利用 CPU 多核,提升性能。
    处于 Power-save mode 时,irqbalance 会将中断集中分配给第一个 CPU,以保证其它空闲 CPU




      [获取更多。。]
    一个用户SQL慢查询分析,原因及优化
    +0 Vote Up -0Vote Down

    问题描述

    一个用户反映线上一个SQL语句执行时间慢得无法接受。SQL语句看上去很简单(本文描述中修改了表名和字段名):
    SELECT count(*)  FROM  a  JOIN  b ON  a.`S` = b.`S` WHERE a.`L` > '2014-03-30 00:55:00' AND a.`L` < '2014-03-30 01:00:00' ; 
    
    且查询需要的字段都建了索引,表结构如下:
    CREATE TABLE `a` (
      `L` timestamp NOT NULL DEFAULT '2000-01-01 00:00:00',
      `I` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `A` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `S` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      `F` tinyint(4) DEFAULT NULL,
      `V` varchar(256) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '',
      `N` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
      KEY `IX_L` (`L`),
      KEY `IX_I` (`I`),
      KEY `IX_S` (`S`)
    ) ENGINE=InnoDB DEFAULT
      [获取更多。。]
    表示 进入内容 130564 下一步 30 较早的记录

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.