13518219792
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
目前创新互联已为千余家的企业提供了网站建设、域名、网络空间、绵阳服务器托管、企业网站设计、纳溪网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)
先来说说临时表的概念。 临时表顾名思义，就是临时的，用完销毁掉的表。 数据既可以保存在临时的文件系统上，也可以保存在固定的磁盘文件系统上。 临时表有下面几种：
1全局临时表
这种临时表从数据库实例启动后开始生效，在数据库实例销毁后失效。在MySQL里面这种临时表对应的是内存表，即memory引擎。
2会话级别临时表
这种临时表在用户登录系统成功后生效，在用户退出时失效。在MySQL里的临时表指的就是以 create temporary table 这样的关键词创建的表。
3事务级别临时表
这种临时表在事务开始时生效，事务提交或者回滚后失效。 在MySQL里面没有这种临时表，必须利用会话级别的临时表间接实现。
4检索级别临时表
这种临时表在SQL语句执行之间产生，执行完毕后失效。 在MySQL里面这种临时表不是很固定，跟随MySQL默认存储引擎来变化。比如默认存储引擎是MyISAM,临时表的引擎就是MyISAM,并且文件生成形式以及数据运作形式和MyISAM一样，只是数据保存在内存里；如果默认引擎是INNODB，那么临时表的引擎就是INNODB，此时它的所有信息都保存在共享表空间ibdata里面。
MySQL 5.7对于InnoDB存储引擎的临时表空间做了优化。在MySQL 5.7之前，INNODB引擎的临时表都保存在ibdata里面，而ibdata的贪婪式磁盘占用导致临时表的创建与删除对其他正常表产生非常大的性能影响。在MySQL5.7中，对于临时表做了下面两个重要方面的优化：
MySQL5.7 把临时表的数据以及回滚信息（仅限于未压缩表）从共享表空间里面剥离出来，形成自己单独的表空间，参数为innodb_temp_data_file_path。
在MySQL5.7 中把临时表的相关检索信息保存在系统信息表中：information_schema.innodb_temp_table_info. 而MySQL 5.7之前的版本想要查看临时表的系统信息是没有太好的办法。
需要注意的一点就是，虽然INNODB临时表有自己的表空间，但是目前还不能自己定义临时表空间文件的保存路径，只能是继承innodb_data_home_dir。此时如果想要拿其他的磁盘，比如内存盘来充当临时表空间的保存地址，只能用老办法，做软链。举个小例子：
我现在用的OS是 Ubuntu12.X，想用tmpfs文件系统充当临时表空间，
root@ytt-master-VirtualBox:/usr/local/mysql/data# ln -s/run/shm/ /usr/local/mysql/data/tmp_space2
root@ytt-master-VirtualBox:/usr/local/mysql/data#ls -l | grep 'shm'
lrwxrwxrwx1 root root 9 Nov 13 10:28tmp_space2 - /run/shm/
然后把
innodb_temp_data_file_path=tmp_space2/ibtmp2:200M:autoextend
添加到my.cnf里的[mysqld]下面一行
重启MySQL服务后，
mysqlselect @@innodb_temp_data_file_path\G
***************************1. row ***************************
@@innodb_temp_data_file_path:tmp_space2/ibtmp2:200M:autoextend
1 rowin set (0.00 sec)
先写一个批量创建临时表的存储过程：
DELIMITER$$
USE`t_girl`$$
DROPPROCEDURE IF EXISTS `sp_create_temporary_table`$$
CREATEDEFINER=`root`@`localhost` PROCEDURE `sp_create_temporary_table`(
IN f_cnt INT UNSIGNED )
BEGIN
DECLARE i INT UNSIGNED DEFAULT 1;
WHILE i = f_cnt
DO
SET @stmt = CONCAT('create temporarytable tmp',i,' ( id int, tmp_desc varchar(60));');
PREPARE s1 FROM @stmt;
EXECUTE s1;
SET i = i + 1;
END WHILE;
DROP PREPARE s1;
END$$
DELIMITER;
现在来创建10张临时表：
mysqlcall sp_create_temporary_table(10);
QueryOK, 0 rows affected (0.07 sec)
如果在以前，我们只知道创建了10张临时表，但是只能凭记忆或者手工记录下来临时表的名字等信息。
现在可以直接从数据字典里面检索相关数据。
mysql select * frominformation_schema.innodb_temp_table_info;
+----------+--------------+--------+-------+----------------------+---------------+
|TABLE_ID | NAME | N_COLS | SPACE| PER_TABLE_TABLESPACE | IS_COMPRESSED |
+----------+--------------+--------+-------+----------------------+---------------+
| 56 | #sql1705_2_9 | 5 | 36 | FALSE | FALSE |
| 55 | #sql1705_2_8 | 5 | 36 | FALSE |FALSE |
| 54 | #sql1705_2_7 | 5 | 36 | FALSE | FALSE |
| 53 | #sql1705_2_6 | 5 | 36 | FALSE | FALSE |
| 52 | #sql1705_2_5 | 5 | 36 | FALSE |FALSE |
| 51 | #sql1705_2_4 | 5 | 36 | FALSE | FALSE |
| 50 | #sql1705_2_3 | 5 | 36 | FALSE | FALSE |
| 49 | #sql1705_2_2 | 5 | 36 | FALSE |FALSE |
| 48 | #sql1705_2_1 | 5 | 36 | FALSE | FALSE |
| 47 | #sql1705_2_0 | 5 | 36 | FALSE | FALSE |
+----------+--------------+--------+-------+----------------------+---------------+
10rows in set (0.00 sec)
功能性我就写到这里，大家性能方面如果有兴趣可以找时间去测试。
都新年了，还出问题了，还想说新年快乐呢！哇哈哈。如下是官方解释：
--------------------------------------------------------------------------------------------
Sending data
The thread is reading and processing rows for a SELECT statement, and sending data to the client. Because operations occurring during this this state tend to perform large amounts of disk access (reads), it is often the longest-running state over the lifetime of a given query.
-------------
换句话说，你的sql查询消耗的IO太多了，磁盘利用的太高了。
第一：优化SQL，建立索引啦，更改表设计啦，这些。
第二：对于经常查询的数据如果不多可采用mysql内存表
第三：CRUD优先级导致select征用。提高查询优先级这个不建议使用。
第四：使用inodb引擎
第五：分区，减少锁竞争。
。。。。
不说了，自己优化查询速度就可以解决这个问题。
在开始演示之前，我们先介绍下两个概念。
概念一，数据的可选择性基数，也就是常说的cardinality值。
查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步操作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。
比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。
那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。
概念二，关于HINT的使用。
这里我来说下HINT是什么，在什么时候用。
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。
比如：表t1经过大量的频繁更新操作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？
来看下具体演示
譬如，以下两条SQL，
A：
select * from t1 where f1 = 20;
B：
select * from t1 where f1 = 30;
如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。
这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。
那回到正题上，MySQL 8.0 带来了几个HINT，我今天就举个index_merge的例子。
示例表结构：
mysql desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)
表记录数：
mysql select count(*) from t1;+----------+| count(*) |+----------+| 32768 |+----------+1 row in set (0.01 sec)
这里我们两条经典的SQL：
SQL C：
select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;
SQL D：
select * from t1 where rank1 =100 and rank2 =100 and rank3 =100;
表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。
那我们来看SQL C的查询计划。
显然，没有用到任何索引，扫描的行数为32034，cost为3243.65。
mysql explain format=json select * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "3243.65" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_produced_per_join": 115, "filtered": "0.36", "cost_info": { "read_cost": "3232.07", "eval_cost": "11.58", "prefix_cost": "3243.65", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们加上hint给相同的查询，再次看看查询计划。
这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为441.09，明显比之前的快了好几倍。
mysql explain format=json select /*+ index_merge(t1) */ * from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "441.09" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_produced_per_join": 1103, "filtered": "100.00", "cost_info": { "read_cost": "330.79", "eval_cost": "110.30", "prefix_cost": "441.09", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))" } }}1 row in set, 1 warning (0.00 sec)
我们再看下SQL D的计划：
不加HINT，
mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "534.34" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_produced_per_join": 0, "filtered": "0.07", "cost_info": { "read_cost": "478.84", "eval_cost": "0.04", "prefix_cost": "534.34", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))" } }}1 row in set, 1 warning (0.00 sec)
加了HINT，
mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "5.23" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "100.00", "cost_info": { "read_cost": "5.13", "eval_cost": "0.10", "prefix_cost": "5.23", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))" } }}1 row in set, 1 warning (0.00 sec)
对比下以上两个，加了HINT的比不加HINT的cost小了100倍。
总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。
哎！你这问题简单也相当不简单。
这个是数据库实时问题，也算是技术难度很高的话题。本不想回答的。但是又问到了我。
原因很简单，本来就是一个答题系统，却要用监控系统的实时性，从成本上说，你认为合适么？
如果数据极为重要还要配置UPS。实时系统的成本很高。
第一：你可以考虑一下mysql 内存表，这个在多连接中是共享的，创建也很简单。但是毕竟mysql不是实时数据库，大并发内存表也一样死锁。断电数据就消失，还要考虑保存问题。
第二：你可以考虑自己创建缓冲层代码，先更新缓冲层，然后写入数据库。只是一个变通问题。
然后每次访问缓冲层即可。
如果是ASP.NET，你可以使用感知缓存功能开发，比java容易的多。
目前对实时要求高的，基本是内存数据库，嵌入式数据库等。肯定不能把时间浪费在IO传输上。
