Database

对于 MySQL 误删数据，如何通过二进制日志进行数据查找和恢复 ...

继《关于 mysql 中 max 函数和 groupby 联合使用的坑》后进一步关于 SQL 性能的探究 类型 解释 id select 查询的序列号 select_type select 查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询 table 输出的行所引用的表 type 联合查询所使用的类型 possible_keys MySQL 能使用哪个索引在该表中找到行 key MySQL 实际决定使用的键 key_len MySQL 决定使用的键长 ref 哪个字段或常数与 key 一起被使用 rows mysql 要遍历多少数据才能找到，在 innodb 上是不准确的 Extra - 实例解释 mysql> desc t3; +-------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | other | varchar(255) | YES | | NULL | | +-------+--------------+------+-----+---------+----------------+ 2 rows in set mysql> select * from (select * from (select * from t3 where id = 3952602) a) b; +---------+-------+ | id | other | +---------+-------+ | 3952602 | sth | +---------+-------+ 1 row in set mysql> explain select * from (select * from (select * from t3 where id = 3952602) a) b; +----+-------------+------------+--------+-------------------+---------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+-------------------+---------+---------+-------+------+-------+ | 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | NULL | | 2 | DERIVED | <derived3> | system | NULL | NULL | NULL | NULL | 1 | NULL | | 3 | DERIVED | t3 | const | PRIMARY,idx_t3_id | PRIMARY | 4 | const | 1 | NULL | +----+-------------+------------+--------+-------------------+---------+---------+-------+------+-------+ 3 rows in set mysql> show index from t3; +-------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +-------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | t3 | 0 | PRIMARY | 1 | id | A | 1 | NULL | NULL | | BTREE | | | | t3 | 1 | idx_t3_id | 1 | id | A | 1 | NULL | NULL | | BTREE | | | +-------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 2 rows in set id 从里往外执行，从 id 为 3 往上执行...

关于朋友随手抛出的一段 SQL，发现 MySQL 中关于 max()和 group by 联合使用中的一个坑，特此整理。 YH:老铁们，这段 hql 对不对啊 我扫了一眼，总觉得看着别扭，自己试着去掉字符串拼接，还原出 SQL 来看，依然感觉不对，然后自己试着写了查询，在本地建个表，造了些数据，用简化后的 SQL 做测试时， 当我定睛检查以下这句 SQL select predictId, max(evaluateDate) evalDate, productId from productcashpredict group by productId; 抛出一个疑问，MySQL 是从后往前执行，先分组再求分组结果中 evaluateDate 最大的记录呢？还是先找出 evaluateDate 的最大记录，再分组呢？ 网上查了查，发现，都不是！这里有个坑！如果直接这么结合 max 和 group by 使用，查出的结果，除了求 max 的字段和分组条件 productId 字段，其他字段的值都是错的！ 首先我在本地验证了一下是不是的确如此 desc productcashpredict; predictId int(11) NO PRI auto_increment evaluateDate datetime YES on update CURRENT_TIMESTAMP other varchar(255) YES productId int(11) YES select * from productcashpredict +-----------+---------------------+-------+-----------+ | predictId | evaluateDate | other | productId | +-----------+---------------------+-------+-----------+ | 1 | 2017-10-31 18:14:37 | NULL | 10001 | | 2 | 2017-10-31 18:14:45 | NULL | 10002 | | 3 | 2017-10-31 18:14:59 | NULL | 10002 | | 4 | 2017-10-31 18:15:09 | NULL | 10003 | | 5 | 2017-10-31 18:15:22 | NULL | 10001 | +-----------+---------------------+-------+-----------+ select predictId, max(evaluateDate) evalDate, productId from productcashpredict group by productId; +-----------+---------------------+-----------+ | predictId | evalDate | productId | +-----------+---------------------+-----------+ | 1 | 2017-10-31 18:15:22 | 10001 | | 2 | 2017-10-31 18:14:59 | 10002 | | 4 | 2017-10-31 18:15:09 | 10003 | +-----------+---------------------+-----------+ 直接这样查的确是错的，看 predictId 可以看出...

mysql 远端数据库与本地数据库间导入导出 远程数据库导出 mysqldump -hxxx -uxxx -pxxx 数据库名 > 脚本名.sql sz 脚本名.sql（SecureCRT 将文件下载到本地） 本地数据库导入 若直接用 navicat 运行本脚本，失败 打开 cmd，进入本地数据库，mysql -uxxxx -pxxxx，use 创建好的数据库 source 脚本名.sql，可以将 2MB 以上的 sql 脚本导入 成功执行，完成远端数据库到本地的克隆