MySQL中实现高性能高并发计数器方案_MySQL教程

推荐：创建MySQL从库
我们知道Oracle有DataGuard实时备份数据，可以做主备切换，而MySQL也有自己的一套备库方案，称之为主从复制。 搭建MySQL从库是为了实时同步主库数据，同时也可以分担主库的读压力，对数据库端做成读写分离结构。 搭建MySQL主从库注意点： 1.主库和从库的 server-id 一

 　　现在有很多的项目，对计数器的实现甚是随意，比如在实现网站文章点击数的时候，是这么设计数据表的，如：”article_id, article_name, article_content, article_author, article_view……在article_view中记录该文章的浏览量。诈一看似乎没有问题。对于小站，比如本博客，就是这么做的，因为小菜的博客难道会涉及并发问题吗?答案显而易见，一天没多少IP，而且以后不会很大。

　　言归正传，对文章资讯类为主的项目，在浏览一个页面的时候不但要进行大量的查(查询上文的记录，已经所属分类的名字、热门文章资讯评论、TAG等)，还要进行写操作(更新浏览数点击数)。把文章的详细内容和计数器放在一张表尽管对开发很方便，但是会造成数据库的压力过大(不然为什么大项目都要分库分表呢)。

　　那么，分两张表存放就好了么?一张表存文章详细信息，另一张表单独存计数器。

　　代码如下:

　　CREATE TABLE `article_view`(

　　`article_id` int(11) NOT NULL,

　　`view` int(11) NOT NULL,

　　PRIMARY KEY (`article_id`)

　　)ENGINE=InnoDB;

　　这种方式，虽然分担了文章表的压力，但是每当有一个进程请求更新的时候，都会产生全局的互斥锁，只能串行，不能并行。在高并发下会有较长的等待时间。

　　另一种比较好的办法是对每一个文章的计数器不是一行，而是多行，比如吧，一百行。每次随机更新其中一行，该文章的浏览数就是所有行的和。

　　代码如下:

　　CREATE TABLE `article_view`(

　　`article_id` int(11) NOT NULL,

　　`pond` tinyint(4) NOT NULL COMMENT '池子，就是用来随机用的',

　　`view` int(11) NOT NULL,

　　PRIMARY KEY (`article_id`,`pond`)

　　)ENGINE=InnoDB;

　　小访问量的随机池子100个肯定多了，三五个足矣。每次访问的时候，随机一个数字(1-100)作为pond，如何该pond存在则更新view+1，否则插入，view=1。借助DUPLICATE KEY，不然在程序里是实现得先SELECT，判断一下再INSERT或者UPDATE。

　　代码如下:

　　INSERT INTO `article_view` (`article_id`, `pond`, `view`) VALUES (`123`, RAND()*100, 1) ON DUPLICATE KEY UPDATE `view`=`view`+1

　　获取指定文章的总访问量的时候：

　　代码如下:

　　SELECT SUM(`view`) FROM `article_view` WHERE `article_id`='123'

　　PS：凡事都是双刃剑。为了更快的读我们通常要牺牲一些东西。在读比较多的表要加快读的速度，在写较多的表要加快写的速度。各自权衡。在加快读的速度的时候，我们牺牲的并不仅仅是写的性能，还有开发成本，开发变的更复杂，维护成本等。所以并不是读的速度越快越好，需要找一个平衡点。

分享：mysql语句中使用like后面的%（百分号）的问题
问题：mysql语句中使用like后面的%(百分号) 是不是越多执行效率越慢! 总用时：0.0489秒 0.0691 0.0485 0.0467 SELECT `goods_name`, `goods_img`, `sku_id`, `import` FROM `goods` WHERE `goods_name` LIKE '%iPhone%iPod%' AND `stime` 1413877244 AND `etime` 14138