Planet MySQL Planet MySQL: Meta English Deutsch Español Français Italiano 日本語 Русский Português
表示 进入内容 110589 下一步 10 较早的记录
旋轉的MySQL慢日誌
+0 Vote Up -0Vote Down
Original post: http://anothermysqldba.blogspot.com/2014/10/rotating-mysql-slow-logs.html

同時與不同的客戶工作,我碰巧會遇到的非常大的慢日誌文件時有發生。 雖然他們如何應該旋轉的若干意見存在。 許多這些意見使用日誌旋轉和刷新日誌的命令,我不喜歡,雖然我刷新二進制日誌。 這就是為什麼我同意羅納德·布拉德福德的

  [获取更多。。]
限制,而不是纵容
+0 Vote Up -0Vote Down

限制,而不是纵容

mysql使用过程中遇到 Too many connections错误的时候,很多dba或者sa第一步操作是 增大 max_connections 参数,尝试恢复服务; 第二步操作是找出罪魁祸首,检查一下究竟是哪个用户(应用)创建了太多的连接,然后再由该应用的RD去检查自己的程序。

能够做到这二点,在很多公司里面已经足够了,dba体现了自己的技术实力,直接解决了问题或者推进了问题的解决,同时表示自己不是整天没有事情做的。

可是,你要清楚,资源并非无限制的,随着connections数量的增加,资源的消耗(内存,CPU等)也会增加。 根本的解决办法应该是限制,而不是纵容。

  [获取更多。。]
mysql set and show system variables
+0 Vote Up -0Vote Down

mysql set and show system variables

mysql中的system variables的作用域有两种:global与session。

set system variables的操作比较简单:

SET GLOBAL sort_buffer_size=1000000;
SET SESSION sort_buffer_size=1000000;

show system variables 与set操作类似,也分为global与session,不多举例。

Global与Session看起来是二种作用域,但是从system variables是否支持global与session的角度来讲, 又可以分为三种情况:
1) 只支持global。
2) 同时支持global与session。
3) 只支持session。

最容易使人困惑的就是第二种情况了,经常可以遇到以下的情况:

SET GLOBAL xxxx=1;
然后
SHOW VARIABLES LIKE 'xxxx';
会发现xxxx的值没有发生变化....

因为不指定global或者session的时候,session为默认值。




  [获取更多。。]
[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响
+0 Vote Up -0Vote Down

本次,我们来看看索引、提交频率对InnoDB表写入速度的影响,了解有哪些需要注意的。

先直接说几个结论吧:

1、关于索引对写入速度的影响:
a、如果有自增列做主键,相对完全没索引的情况,写入速度约提升 3.11%;
b、如果有自增列做主键,并且二级索引,相对完全没索引的情况,写入速度约降低 27.37%;

因此,InnoDB表最好总是有一个自增列做主键。

2、关于提交频率对写入速度的影响(以表中只有自增列做主键的场景,一次写入数据30万行数据为例):

a、等待全部数据写入完成后,最后再执行commit提交的效率最高;
b、每10万行提交一次,相对一次性提交,约慢了1.17%;
  [获取更多。。]
MySQL的用戶連接
+0 Vote Up -0Vote Down
Original post: http://anothermysqldba.blogspot.com/2014/09/mysql-user-connections.html 
所以,我發現自己解釋與MySQL的用戶,以及他們如何進行身份驗證的差異。 首先,這些信息是不是新的,但可以在這裡找到: 我只展示一些真實世界的例子來說明這一點。
MySQL使用的用戶名和登錄時,計算一個用戶的權限。

  [获取更多。。]
[MySQL FAQ]系列 — MySQL联合索引是否支持不同排序规则
+0 Vote Up -0Vote Down

篇首语:
截止到目前的5.7.4版本为止,MySQL的联合索引仍无法支持联合索引使用不同排序规则,例如:ALTER TABLE t ADD INDEX idx(col1, col2 DESC)。

先来了解下MySQL关于索引的一些基础知识要点:

• a、EXPLAIN结果中的key_len只显示了条件检索子句需要的索引长度,但 ORDER BY、GROUP BY 子句用到的索引则不计入 key_len 统计值;
• b、联合索引(composite index):多个字段组成的索引,称为联合索引;
例如:ALTER TABLE t ADD INDEX `idx` (col1, col2, col3)
• c、覆盖索引(covering index):如果查询需要读取到索引中的一个或多个字段,则可以从索引树中直接取得结果集,称为覆盖索引;
例如:SELECT col1, col2 FROM t;
• d、最左原则(prefix

  [获取更多。。]
[MySQL FAQ]系列 — SAVEPOINT语法错误一例
+0 Vote Up -0Vote Down

前几天帮同事解决一个案例,在主从复制环境下,从库上的MySQL版本号是5.5.5,遇到下面的错误:

#其他非相关信息我都隐藏掉了
 [(yejr@imysql.com)]> show slave status \G;
 Slave_IO_Running: Yes
 Slave_SQL_Running: No
 Last_Errno: 1064
 Last_Error: Error 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '6e86db84_14847168f19__8000' at line 1' on query. Default database: 'act'. Query: 'SAVEPOINT 6e86db84_14847168f19__8000'
 Last_IO_Errno: 0
 Last_IO_Error:
 Last_SQL_Errno: 1064
 Last_SQL_Error: Error 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '6e86db84_14847168f19__8000' at line 1' on query. Default database: 'act_log'. Query: 'SAVEPOINT
  [获取更多。。]
新增sysbench和tpcc-mysql源码包下载
+0 Vote Up -0Vote Down

sysbench从sourceforge迁移到launchpad上了,代码管理改成了Bazaar,但很多人应该都没安装bzr客户端,因此我从launchpad服务器上把sysbench源码包checkout一份到本地,顺手把tpcc-mysql的源码包也下载了。本站下载地址见下:

sysbench-0.4.12-1.1.tgz

tpcc-mysql-src.tgz

复杂关联SQL的优化
+0 Vote Up -0Vote Down

昨天处理了一则复杂关联SQL的优化,这类SQL的优化往往考虑以下四点:

第一.查询所返回的结果集,通常查询返回的结果集很少,是有信心进行优化的;

第二.驱动表的选择至关重要,通过查看执行计划,可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在;

第三.理清各表之间的关联关系,注意关联字段上是否有合适的索引;

第四.使用straight_join关键词来强制表之间的关联顺序,可以方便我们验证某些猜想;

SQL:
执行时间:
mysql> select c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
-> from a, b, c
-> left












  [获取更多。。]
[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键
+0 Vote Up -0Vote Down

我们先了解下InnoDB引擎表的一些关键特征:

  • InnoDB引擎表是基于B+树的索引组织表(IOT);
  • 每个表都需要有一个聚集索引(clustered index);
  • 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree);
  • 基于聚集索引的增、删、改、查的效率相对是最高的;
  • 如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引;
  • 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引;
  • 如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用,是隐含的)。
  [获取更多。。]
表示 进入内容 110589 下一步 10 较早的记录

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.