花荣老师的博客

假设我们有一张表，用来记录广告点击情况的。每天的数据大概100万行左右。
在每天0:00的时候，要对这张表的数据进行分析，然后归档数据，再清空整张表。
我们以前的做法就是写个cron，0点开始执行，大概执行3-5分钟即可完毕。
注意：在这个过程中，仍然不断有新数据会被写入。
虽然这种办法统计到的结果包含一些0点之后的数据，但也没有大碍,整体看来还是可以接受的。

今天看了一篇文章，非常佩服作者的想法：
原文地址：http://tech.ovaistariq.net/2010/06/the-shadow-table-trick

操作步骤如下：
1 创建一个新的table，称之为shadow table， 它和原表有完全相同的结构。
2 使用RENAME TABLE语句，把这二张表交换。shadow table变成线上的表，里面完全没有数据，线上的表变成shadow table，里面包含昨天的所有数据。
3 在新的shadow table上面做统计，归档，清空操作。

举个例子吧：
线上的表，用来记录页面访问的。

CREATE TABLE `hits` (
`ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`post_id` bigint(20) unsigned NOT NULL,
KEY `pp_postid_ts` (`post_id`,`ts`)
) ENGINE=MyISAM;

创建一个shadow table:

CREATE TABLE `hits_shadow` LIKE `hits`;

交换两张表：

RENAME TABLE hits TO hits_temp, hits_shadow TO hits, hits_temp TO hits_shadow;

然后就可以在hits_shadow上面做统计了。

rename table的速度实在是太快了，太爽了，完美。

使用这种办法之后，我们的数据统计更加精确了。

原文http://tech.ovaistariq.net/2010/05/mysql-indexes-multi-column-indexes-and-order-of-columns

很多时候，我们在mysql中创建了索引，但是某些查询还是很慢，根本就没有使用到索引！
一般来说，可能是某些字段没有创建索引，或者是组合索引中字段的顺序与查询语句中字段的顺序不符。

看下面的例子：
假设有一张订单表(orders)，包含order_id和product_id二个字段。
一共有31条数据。符合下面语句的数据有5条。
执行下面的sql语句：

select product_id 
from orders
where order_id in (123, 312, 223, 132, 224);

这条语句要mysql去根据order_id进行搜索，然后返回匹配记录中的product_id。
所以组合索引应该按照以下的顺序创建：

create index orderid_productid on orders(order_id, product_id)

mysql> explain select product_id from orders where order_id in (123, 312, 223, 132, 224) \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: orders
         type: range
possible_keys: orderid_productid
          key: orderid_productid
      key_len: 5
          ref: NULL
         rows: 5
        Extra: Using where; Using index
1 row in set (0.00 sec)

可以看到，这个组合索引被用到了,扫描的范围也很小，只有5行。

如果把组合索引的顺序换成product_id, order_id的话，
mysql就会去索引中搜索 *123 *312 *223 *132 *224，必然会有些慢了。

mysql> create index orderid_productid on orders(product_id, order_id);                                                       
Query OK, 31 rows affected (0.01 sec)
Records: 31  Duplicates: 0  Warnings: 0
 
mysql> explain select product_id from orders where order_id in (123, 312, 223, 132, 224) \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: orders
         type: index
possible_keys: NULL
          key: orderid_productid
      key_len: 10
          ref: NULL
         rows: 31
        Extra: Using where; Using index
1 row in set (0.00 sec)

这次索引搜索的性能显然不能和上次相比了。
rows:31，我的表中一共就31条数据。
索引被使用部分的长度：key_len:10，比上一次的key_len:5多了一倍。
不知道是这样在索引里面查找速度快，还是直接去全表扫描更快呢？

mysql> alter table orders add modify_a char(255) default 'aaa';
Query OK, 31 rows affected (0.01 sec)
Records: 31  Duplicates: 0  Warnings: 0
 
mysql> 
mysql> 
mysql> explain select modify_a from orders where order_id in (123, 312, 223, 132, 224) \G          
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: orders
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 31
        Extra: Using where
1 row in set (0.00 sec)

这样就不会用到索引了。 刚才是因为select的product_id与where中的order_id都在索引里面的。

为什么要创建组合索引呢？这么简单的情况直接创建一个order_id的索引不就行了吗？
如果只有一个order_id索引，没什么问题，会用到这个索引，
然后mysql要去磁盘上的表里面取到product_id。
如果有组合索引的话，mysql可以完全从索引中取到product_id，速度自然会快。

再多说几句组合索引的最左优先原则：
组合索引的第一个字段必须出现在查询组句中，这个索引才会被用到。
如果有一个组合索引(col_a,col_b,col_c)
下面的情况都会用到这个索引：

col_a = "some value";
col_a = "some value" and col_b = "some value";
col_a = "some value" and col_b = "some value" and col_c = "some value";
col_b = "some value" and col_a = "some value" and col_c = "some value";

对于最后一条语句，mysql会自动优化成第三条的样子~~。

下面的情况就不会用到索引：

col_b = "aaaaaa";
col_b = "aaaa" and col_c = "cccccc";

原文地址：

http://www.xaprb.com/blog/2010/09/04/why-mysql-replication-is-better-than-mysqlbinlog-for-recovery

通常，我们在恢复mysql数据的时候，都是恢复一个完整的备份，
再通过mysqlbinlog来导入此备份之后的二进制日志（binary logs）
这里有另外一个更好的方法:

操作如下：
首先恢复一个完整的备份，假设此服务器为SERVER_A。
然后在另外一台服务器SERVER_B上面，安装一个新的mysql，复制过去二进制日志文件和二进制日志的索引文件(index)，然后启动mysqld,设置为主服务器。
最后把SERVER_A设置为 SERVER_B的从服务器，从第一个二进制日志文件的position 0 开始 replication复制。

为什么这个方法更好呢？

因为测试证明，replication比mysqlbinlog更加可靠。

比如下面这条语句：
insert into tbl(col) values(connection_id());
使用mysqlbinlog进行恢复，肯定会得到错误的结果。

而且在某些版本的mysql上，BLOB类型的数据无法通过mysqlbinlog恢复。
详见：http://bugs.mysql.com/bug.php?id=33048

而且replication更加灵活，你可以使用start slave until 等语句，
还可以暂时停止复制，继续复制等等。

mysql 时间函数

mysql> select now(), current_date(), current_time(), unix_timestamp();
+---------------------+----------------+----------------+------------------+
| now()               | current_date() | current_time() | unix_timestamp() |
+---------------------+----------------+----------------+------------------+
| 2010-04-13 10:32:04 | 2010-04-13     | 10:32:04       |       1271125924 |
+---------------------+----------------+----------------+------------------+

mysql> select FROM_UNIXTIME(1271125924), unix_timestamp('2010-04-13 10:32:04');
+---------------------------+---------------------------------------+
| FROM_UNIXTIME(1271125924) | unix_timestamp('2010-04-13 10:32:04') |
+---------------------------+---------------------------------------+
| 2010-04-13 10:32:04       |                            1271125924 |
+---------------------------+---------------------------------------+

mysql> select TO_DAYS('2010-04-13 22:33:11'), from_days(734240);
+--------------------------------+-------------------+
| TO_DAYS('2010-04-13 22:33:11') | from_days(734240) |
+--------------------------------+-------------------+
|                         734240 | 2010-04-13        |
+--------------------------------+-------------------+

year('2010-04-13 22:33:11'): 2010
        month('2010-04-13'): 4
    monthname('2010-04-13'): April
   dayofmonth('2010-04-13'): 13
    dayofyear('2010-04-13'): 103
    dayofweek('2010-04-13'): 3
      weekday('2010-04-13'): 1
hour('2010-04-13 22:33:11'): 22
         minute('22:33:11'): 33
         second('22:33:11'): 11
1 row in set (0.00 sec)

注:2010-04-13是星期二

                      "1997-12-31 23:59:59" + INTERVAL 1 SECOND: 1998-01-01 00:00:00
                                  INTERVAL 1 DAY + "1997-12-31": 1998-01-01
                               "1998-01-01" - INTERVAL 1 SECOND: 1997-12-31 23:59:59
             DATE_ADD("1997-12-31 23:59:59", INTERVAL 1 SECOND): 1998-01-01 00:00:00
               DATE_ADD("1997-12-31 23:59:59",  INTERVAL 1 DAY): 1998-01-01 23:59:59
 DATE_ADD("1997-12-31 23:59:59",  INTERVAL "1:1" MINUTE_SECOND): 1998-01-01 00:01:00
DATE_SUB("1998-01-01 00:00:00",  INTERVAL "1 1:1:1" DAY_SECOND): 1997-12-30 22:58:59
    DATE_ADD("1998-01-01 00:00:00",  INTERVAL "-1 10" DAY_HOUR): 1997-12-30 14:00:00
                        DATE_SUB("1998-01-02", INTERVAL 31 DAY): 1997-12-02
                                EXTRACT(YEAR FROM "1999-07-02"): 1999
                 EXTRACT(YEAR_MONTH FROM "1999-07-02 01:02:03"): 199907
                 EXTRACT(DAY_MINUTE FROM "1999-07-02 01:02:03"): 20102