您正在查看 "Mysql" 分类下的文章 2012年01月29日 星期日 11:21 2011年09月25日 星期日 2:05 mark it 在根据主键查询或者唯一性索引查询是出现：Extra: Impossible WHERE noticed after reading const tables explain走到这个方式，会很慢，一个空表也是如此，在并发量高的情况下存在相互的等待，因为他要判断之。 如果直接走索引的方式，那么效率就非常高。 奇怪mysql要整这么个东西干啥 http://wangyuanzju.blog.163.com/blog/stat |
2011年08月23日 星期二 4:09 2011年08月21日 星期日 0:35 ./mk-query-digest slow.log --如此简单就可以分析mysql的慢日志，当然如果slow log很大时，这么做会消耗很大的性能。 主要参数： --limit: default: 95%:20 Limit output to the given percentage or count. --select: Compute aggregate statistics for these attributes. (Query_time,Lock_time,Rows_sent,Rows_examin |
2011年06月17日 星期五 12:09 一个innod的表，如果根据没有索引的列去更新，那么很悲剧，会lock整个表。
update tmp_xf set c |
2011年05月29日 星期日 22:08 mysql备库处理binlog日志是单线程的，无论主库有多少个database或者主库的tps有多高，备库当前的恢复模式都是单进程恢复。这样解决了并发的问题，但是也是备库很容易在主库高tsp的情况下，造成延迟。 一些情况下，备库的延迟可以通过预热来加快sql的执行速度。预热就是将需要更新的数据提取进行select，将数据缓存到内存，减少恢复进程执行时的IO消耗。 但当更新的数据很随机，数据量远远大于buffer pool大小时就不适用了。 数据库的tps上不去，负载过高，同时备库延迟，很多情况下是由于磁盘IO的压力导致的，如果重 |
2011年05月29日 星期日 20:18 之前写过关于mysql取随机数的记录，当时没有去分析表里数据量的分布情况，所以当执行计划不同时，实际的效果有非常大的差别。 dbaeyes 06:47:52>select count( |
2011年05月29日 星期日 19:24 在取mysql主键最大最小值时，mysql会使用最优方式 SELECT tables optimized away 官方解释
SELECT tables optimized away：当我们使用某些聚合函数来访问存在索引的某个字段时，MySQL Query Optimizer 会通过索引直接一次定位到所需的数据行完成整个查询。当然，前提是在 Query 中不能有 GROUP BY 操作。如使用MIN()或MAX()的时候 root@wap 06:57:32>explain select max(id) from tmp_xf; +----+-------------+-------+------+---------------+------+---------+--- |
2011年04月14日 星期四 14:02 Mark IGNORE is a MySQL extension to standard SQL. It controls how ALTER TABLE works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. If IGNORE is not specified, the copy is aborted and rolled back if duplicate-key errors occur. If IGNORE is specified, only the first row is used of rows with duplicates on a unique k |
2011年02月24日 星期四 21:36 简单mark --- root@bbc 09:32:30>create table tmp_xf(i int(4) zerofill); Query OK, 0 rows affected (0.01 sec) root@bbc 09:32:42>insert into tmp_xf values(12); Query OK, 1 row affected (0.00 sec) root@bbc 09:32:49>select * from tmp_xf; +------+ | i | +------+ | 0012 | +------+ 1 row in set (0.00 sec) ################### root@bb |
2011年01月26日 星期三 18:47 简单记录-- select * into outfile '/home/mysql/tmp_xxxx.txt' from test_xf; $cat tmp_xxx.txt 1 a 2011-01-26 17:23:25 2 a,b \N 3 cc'"c \N |
2010年08月31日 星期二 10:31 mysql表或分表的数据达到一定量（也许是800w或者1000w..）这个时候非常需要再分表，简单的办法是直接写
--假设根据user_id分表，分成64张
insert into table_new_0000 select * from table_old where mod(user_id,64)=0;
insert into table_new_0001 select * from table_old where mod(user_id,64)=1;
...
一共64条sql，OK 搞定。 但是这个一张表被全表扫描了64次，做的无用功比较多，而且导致停机时间比较长。
虽然mysql的存储过程不是很熟，稍稍学习了下写了两个脚本，一个全量+一个增量脚本完 |
2010年08月09日 星期一 17:02
当一个表mysql的表成长到1000w以上，然后需要更加某些条件去删除其中的几百万数据的时候，如果直接delete将是一件极其痛苦的事情。 时间长是必然的，而且堵塞了正常应用的更新等操作，很有可能的导致数据库hang住和应用的崩溃
--常用的方法，如果表是1000w，符合删除条件的数据是400w的话，那时间一般会超过半个小时乃至更长
delete from xf_user_info where status=2 and date(gmt_create) < '2010-07-01';
----------使用类似于oracle常用的方式来完成，如果有更好的方法，不吝赐教
--
|
2010年06月10日 星期四 14:45 ---
root@test 10:56:20>explain SELECT T0.*
-> FROM
-> PRODUCT_0000 T0,
-> PRODUCT_0003 T3
-> WHERE T0.ID = T3.id
-> AND T0.AUC_ID =5120001280;
+----+-------------+-------+--------+-------------------------+-----------------+---------+--------------------+------+-------------+
| id | select_type | table | type | possible_keys | key |
2010年05月19日 星期三 14:47 小测一下 mysql的limit 的扫描行数 和order by和索引的关系
--查询条件字段都在索引里，数据都已经在数据库cache中
索引如下
KEY `IDX_USER_ID` USING BTREE (`user_id`,`do_date`,`SUS`,`r_type`,`rat`)
root@my_db 11:25:04>explain SELECT t2.* from
-> (select id
-> FROM my_test_table FF
-> WHERE user_id = 888
-> AND SUS = 0
-> AND r_type = 0
-> |
| | |
