Planet MySQL Planet MySQL: Meta English Deutsch Español Français Italiano 日本語 Русский Português
表示 进入内容 110590 下一步 10 较早的记录
MySQL 二进制日志格式基础(一)
+0 Vote Up -0Vote Down

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.
MySQL二制进日志用于记录数据库的变更记录,这里从结构上讨论一下日志的格式。

每个日志都包含4个字节的magic number 和event的描述包

  • 日志有前四个字节是magic number: oxfe ox62 0×69 0x6e = 0xfe ‘b”i”n’ 转成整数:1852400382  用处就是读4个字节对比不是这个数,说明就不是二进制日志,就不用处理了。
      log_event.sh中可以查到
      /* 4 bytes which all binlogs should begin with */
         #define BINLOG_MAGIC        "\xfe\x62\x69\x6e"
    
  • 每个event的header大概如下:
     - 每个event中包含:

  •   [获取更多。。]
    旋轉的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












      [获取更多。。]
    表示 进入内容 110590 下一步 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.