【RDS系列二】别总等数据库宕了才想起我

你那么多数据使用like肯定不行

简单点使用《全文索引》
复杂点使用搜索引擎技术，有些开源系统也挺好用的

小站长用不起啊！

      

-------------------------

  支持 淘宝打折网：http://www.shazhekou.com/      

的的确确 不错

如果你在那个时候就用到了RDS，就不用担心数据丢失了。
RDS提供了恢复到7天之内的任意时间点功能，只需要在控制台上点点按钮，就能恢复到数据丢失前的时间点。
其原理是这样的：
假如要恢复到4月22日中午12：00, 先会拿到该时间点之前最近的一个物理备份集，恢复出全量的数据；再应用从物理备份的时间点到4月22日中午12：00之间的binlog。
所以为了数据安全，建议大家尽量选择每天都做一次物理备份，这些备份集都是免费存在阿里云OSS上的，不占用户空间的。

-------------------------

账号权限开放、支持binlog备份的付费服务，都在产品的排期之内的。RDS团队还在加紧开发。

RDS open API支持查询、下载binlog的。OPEN API文档中有相关接口的说明。

-------------------------

先可以看查询所返回的结果集，通常如果返回的结果集很少，是有信心进行优化的。
需要在过滤性强的字段上建立合适的索引。

使用like进行模糊查询，由于like '%XXXX%'不符合前缀匹配的规则，所以用不上索引，需要全表扫描。
比如在下面的表结构下查询：
       Table: tunning_missindex
Create Table: CREATE TABLE `test1` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `custins_id` int(10) unsigned NOT NULL DEFAULT '0',
  `db_name` varchar(128) DEFAULT NULL ,
  `table_name` varchar(128) DEFAULT NULL ,
   ...........
   ...........
  `gmt_created` datetime NOT NULL ,
  `gmt_modified` datetime NOT NULL ,
  `creator` int(11) unsigned DEFAULT '0' ,
  `modifier` int(11) unsigned DEFAULT '0' ,
  `tuning_advice` text,
  PRIMARY KEY (`id`),
  KEY `idx_tablename` (`table_name`)
) ENGINE=InnoDB AUTO_INCREMENT=12749 DEFAULT CHARSET=utf8

mysql> explain select * from test1 where table_name like '%test%';
+----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
| id | select_type | table             | type | possible_keys | key  | key_len | ref  | rows  | Extra       |
+----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
|  1 | SIMPLE      | test1 | ALL  | NULL          | NULL | NULL    | NULL | 10382 | Using where |
+----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
1 row in set (0.00 sec)

InnoDB表是按照聚簇索引组织的。InnoDB通过主键聚簇数据，如果没有定义主键，会选择一个唯一的非空索引代替，如果没有这样的索引，会隐式定义个主键作为聚簇索引。
对于聚簇索引表来说，表数据是和主键一起存储的，主键索引的叶结点存储行数据，二级索引的叶结点存储行的主键值。
所以，理想情况应该是这个流程
1)       遍历table_name索引，从中读取和过滤所有table_name中匹配like条件的id
2)       用id到聚簇索引中读数据。

对于 select count(*) from test1 where table_name like '%test%'的优化，可以利用到覆盖索引。这样扫描二级索引就可以得到结果，避免再到数据行去查询。
mysql> explain select count(*) from test1 where table_name like '%test%';
+----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
| id | select_type | table             | type  | possible_keys | key           | key_len | ref  | rows  | Extra                    |
+----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
|  1 | SIMPLE      | test1 | index | NULL          | idx_tablename | 387     | NULL | 10382 | Using where; Using index |
+----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
1 row in set (0.00 sec)

通过覆盖索引可以获得性能上的一定优化，但是在数据量特别大，请求频繁的业务场景下不要在数据库进行模糊查询；  
非得使用数据库的话 ，建议不要在生产库进行查询，可以在只读节点进行查询，避免查询造成主业务数据库的资源消耗完，导致故障.  
可以使用一些开源的搜索引擎技术，比如sphinx.  

sql优化的时候遵循T=S/V的原则：
S指SQL所需访问的资源总量，V指SQL单位时间所能访问的资源量，T自然就是SQL执行所需时间了;我们为了获得SQL最快的执行时间，可以根据公式定义上去反推：

在S不变的情况下，我们可以提升V来降低T：通过适当的索引调整，我们可以将大量的速度较慢的随机IO转换为速度较快的顺序IO；通过提升服务器的内存，使得将更多的数据放到内存中，会比数据放到磁盘上会得到明显的速度提升；

在V不变的情况下，我们可以减小S来降低T：这是SQL优化中非常核心的一个环节，在减小S环节上，我们可以做的可以有很多，通常可以在查询条件中建立适当的索引，来避免全表扫描；有时候可以改写SQl，添加一些适当的提示符，来改变SQL的执行计划，使SQL以最少的扫描路径完成查询。

你的wp?

数据库对新手来说就是一个天书文字！遇到问题！白瞪眼啊！！  ps学习网89ps.com  就因为数据库问题！数据全部丢失！！  郁闷啊！

目前最期待的就是权限控制可以细分到表级别，另外就是二进制日志支持更长时间的备份，哪怕是付费···  那天看了下API接口貌似也只有物理备份的下载接口吧，没有二进制的备份接口？

有没有DISCUZ 3.2的数据库优化方案？
可不可以对dz x3.2的数据库优化做一个专题？

感觉是很有用的啊

我们有千万的数据  业务需求 需要做
1、count(*)
2、like '%关键词%'
3、>  或 <  
4、not in(1,2,3)  或  in(1,2,3)

等  常规的操作

  已经按要求建立了索引


  现在的问题是  查询非常慢  经常查询超时  咨询阿里云技术  已经优化mysql语句 但是业务需要避不开 count(*)  like '%%' 等这类语句。


咨询专业技术 看是否有好的解决方案 谢谢     已经困扰很久了 没办法解决  希望阿里强大的技术能协助我们  谢谢

楼主说得很对，但希望你们的价格能低点就好了  (http://www-cqhuinong-cn 重庆潼南网站建设)

周大 你又出来了 好久不见

我们用帝国cms网站系统，就有这些提示，可是不懂数据库，怎么办？

数据库宕了确麻烦，我的站有过一次弄得我头都大了！http://www.jinglingw.com     http://www.025nt.com