在想清楚解决方案、做好全部备份、逐个相关文件关系查验之前，尽量不要做任何文件的写入、覆盖操作。
记一段辛酸但好歹不用跳天台的数据库恢复笔记
能写一个自动备份脚本，为什么要偷几十秒的懒呢？
主要也是参考下面链接最终成功恢复。 这篇文章的步骤稍微有点多。有些是恢复不必要的，这里做一下自己的整理。
数据库目录配置错误时，MySQL是不能正常启动的，报错可能与此无关。 比如说,找不到 user_table这样的报错，都可能是目录配置错误。
在网上可以查到有两种方式查询表的索引
show index from tablename
SELECT * FROM mysql.innodb_index_stats a WHERE a.database_name = '数据库名' and a.table_name like '%表名%';第一种是可行的，问题是在于并不是用SELECT语句，所以就不能和其他的表数据一起查询，譬如说 查询表结构的时候连同索引一起查询。
(第二种来自于网络，实际上语句本身就有错误和低效的like，我们先只看逻辑) 仅看第二种也是不可行的，因为除了ROOT用户以外的用户无法访问innodb_index_stats表，所以是不行的。 在网上翻了很多页面都没有找到合适的解决方案，于是我把所有独立数据库用户身份可以查看的表全部翻看一遍之后发现。STATICS表中是存有索引数据的。
查询方式如下：
SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = basename AND TABLE_NAME = tablename将索引信息和表结构信息一起查看的查询:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS LEFT JOIN INFORMATION_SCHEMA.STATISTICS ON COLUMNS.COLUMN_NAME=STATISTICS.COLUMN_NAME AND COLUMNS.TABLE_NAME = STATISTICS.TABLE_NAME AND STATISTICS.TABLE_SCHEMA = '{$basename}' AND STATISTICS.TABLE_NAME = '{$tablename}' WHERE COLUMNS.TABLE_SCHEMA = '{$basename}' AND COLUMNS.TABLE_NAME = '{$tablename}' 这里一定要注意使用表内筛选 先将STATISTICS表中的数据过滤一遍，再进行合并，两张表都要以basename,tablename进行过滤。否则会有很大概率得到循环嵌套的大量结果！
mysql分别用数字INT和中文varchar做索引查询效率上差多少
性能相当
mysql中区别性能的是采用哪种索引方式，而不是索引的数据类型。
MySQL的btree索引和hash索引的区别
在一个大型的复杂应用中，我们通常会将不同模块的数据存储到各自的表中 例如在APPsite框架中我们默认了4张用户表 分别存储了 user_account 账户表 user_info 详情表 user_pocket 钱包表 user_group 分组表
这样我们在读写数据的时候可以做到表级别的隔离，防止一些api 或是 内外部方法导致的数据泄露问题，提高安全性和事务方法的紧密度。 当然也有一定的减轻单张表结构过于臃肿的作用。
这里的表拆分，要基于业务划分去做，譬如说详情、分组、钱包在用户的鉴权、登录包括收发消息等行为时都不需要，那么我们就可以将这些部分的数据转移到新的表中。保持account表的高效性。
于此对应的是我们在进行后台的丰富数据查询时就需要合并表进行查询，今天特意整理一下使用JOIN进行多表联合查询的注意点。
首先是最简单的范例
# JOIN查询 双表
SELECT * FROM user_account
LEFT JOIN user_info ON user_account.userid = user_info.userid在多表查询时，我们会遇到某个表 对应项目为空时的情况, 这时根据JOIN方式就会有不同的结果。其中INNER 方式就会取交集合并结果，而LEFT方式左表会完整展示，右表不满足条件的数据会被剔除为空。
最近回复