Discuz! 数据库加索引

待优化的 SQL：（pre_forum_thread 表有 150 万条数据）

SELECT * FROM pre_forum_thread  WHERE `fid`='62' AND `displayorder` IN('0','1','2','3','4')  ORDER BY displayorder DESC, dateline DESC    LIMIT 20, 20

加索引前，

EXPLAIN 结果 Extra 为：Using index condition; Using where; Using filesort

> 时间: 0.915s

加索引后：`fid`, `displayorder`, `dateline`

EXPLAIN 结果 Extra 为：Using where 或 Using index condition

> 时间: 0.001s

magapp 数据库加索引

待优化的 SQL：（mag_score_action_log 表有 200 万条数据）

SELECT COUNT(*) AS tp_count
FROM `mag_score_action_log`
WHERE action_id = 20
	AND user_id = 650070
	AND create_time >= 1534953600
	AND create_time < 1535040000
LIMIT 1

加索引前，

EXPLAIN 结果 Extra 为：?????

> 时间: 70s

加索引后：`action_id`, `user_id`, `create_time`

EXPLAIN 结果 Extra 为：Using where; Using index

> 时间: 0.073s

待优化的 SQL：（mag_score_mission_log 表有约 55 万条数据）

SELECT COUNT(*) AS tp_count
FROM `mag_score_mission_log`
WHERE mission_id = 7
	AND user_id = 650070
	AND create_time >= 1534953600
	AND create_time < 1535040000
LIMIT 1

加索引前，

EXPLAIN 结果 rows 为：549178

> 时间: 17.719s

加索引后：`mission_id`, `user_id`, `create_time`

EXPLAIN 结果 rows 为：1

> 时间: 0.025s

待优化的 SQL：（mag_score_mission_user 表有约 28 万条数据）

SELECT *
FROM `mag_score_mission_user`
WHERE `user_id` = 431779
	AND `mission_id` = 5
	AND `create_time` >= 1534953600
ORDER BY complete_count DESC
LIMIT 1

不加索引

1SIMPLEmag_score_mission_userALL282436Using where; Using filesort

> 时间: 7.325s

`user_id`, `mission_id`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where; Using filesort

时间: 0.014s

`user_id`, `mission_id`, `create_time`

1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort

时间: 0.023s

`user_id`, `mission_id`, `complete_count`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where

> 时间: 0.014s

`user_id`, `mission_id`, `complete_count`, `create_time`

1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where

> 时间: 0.028s

`user_id`, `mission_id`, `create_time`, `complete_count`

1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort

> 时间: 0.025s

其它就不一一举例了，根据 SHOW FULL PROCESSLIST 的慢查询自行加索引就行了。

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

本文不定时更新！

A： MySQL 执行 SHOW FULL PROCESSLIST 

Q： 查看连接数和慢查询，适用于 MySQL 数据库无法连接 1040

A： iftop -i eth0

Q： 查看占用带宽的IP（命令：iftop -i eth0 -F ip/24），添加到安全组、防火墙、宝塔的黑名单中。

命令 grep -l "x.x.x.x" /www/wwwlogs/*.log 可以在 wwwlogs 目录下的所有 .log 文件中查找指定的恶意 IP。

A： goaccess -f xxx.log

Q： 实时分析网站日志，查看请求最多的IP

A： net.xoyozo.weblog 日志分析工具

Q： 自制的 Web 日志分析工具，可按多种方式排序，纠出可疑访问

A： 重启 web 服务器

Q： 有时候能解决 CPU 和内存消耗的问题，如果一会儿又升高，则需要找另外的原因

Q： 500 服务器内部错误

502 Bad Gateway

504 Gateway Time-out

A： 查看 php 日志，可能的路径：

/usr/local/php/var/log/php-fpm.log

/www/server/php/[版本]/var/log/php-fpm.log

Q： RDS MySQL IOPS 使用率高的原因和处理

A： 根据时间点查看慢查询

Q： Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等

A： 进入管理中心 - 工具 - 更新缓存，能解决大部分问题

Q： Discuz! 浏览帖子提示“没有找到帖子”

A： 进入数据库，修复表 pre_forum_post 或分表

Q： CPU 100% 或内存 100%，负载100+

A： 原因有很多，以下是一些建议：

Windows 在任务管理器中查看进程

当前是否有正常的大流量访问（譬如民生类论坛的某个帖子突然火了）特别是重启无效的情况

对比网站日志大小可大致确定哪个网站被大量恶意请求。

观察：命令 top

排查：通过关闭网站来确定是某网站的问题，通过关闭功能确定是某功能的问题，如果 nginx 崩溃请参下条

案例：通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的，更新插件和 mobcent 包解决问题。

如果都是正常访问，top 看到很多 php-fpm，而且个个占用 CPU 还不小，那么根据服务器硬件配置来修改 php 的并发量，如宝塔面板在 php 设置 - 性能调整 页，300 并发方案的推荐配置是：

max_children：300
start_servers：30
min_spare_servers：30
max_spare_servers：180

另外，memcached 或 redis 的配置也可以进行相应的修改。

另一个案例是 kswapd0 进程占满 CPU，原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。

也可以通过 iftop 来查询占用带宽较多的 IP 并封禁（出方向），如果 CPU 能降下来，那这个 IP 就是罪魁祸首。

Q： 阿里云 ECS 的 CPU 突然达到 100%，并持续到次日 0:00 左右

A： 可能 ECS 是 t5 规格，受 CPU 积分制度限制，积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。

Q： ASP.NET 所在服务器 CPU 突然达到 50% 或 100%，并持续

A： 首先确定哪个网站，再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。

Q： nginx 服务停止

A： 查看 nginx 日志

WDCP 路径：/www/wdlinux/nginx-1.0.15/logs/error.log

Q： 公网出带宽 100%，其它指标正常

A： Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID，然后在任务管理器-详细信息中的找到对应的用户（如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽）；如果是被 PID 为 4 的 System 占用大部分带宽，也可以尝试重启 IIS 来解决。

CentOS 使用 nethogs 查看占用带宽的进程PID和USER，如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽，否则只能一个个关闭网站来判断，不知道大家有没有好的方法？当然还可以直接用 iftop 命令查看占用带宽的 IP。另外，查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。

A： Linux 显示每个用户会话的登入和登出信息

utmpdump /var/log/wtmp

参考：http://www.tulaoshi.com/n/20160331/2050641.html

Q： RDS 的 CPU 100%

A： 如果是突然持续占满（同时伴随 ECS 资源使用率下降，页面出现 502），很大可能是受攻击（或社交网站推送突发事件等），查看“慢查询”，添加相关索引；如果是 Discuz! 论坛，可尝试修复优化表 pre_common_session。

如果是数日缓步上升，或新项目上线，考虑 SQL 慢查询，思路：MySQL / SQL Server。

MySQL：SHOW FULL PROCESSLIST

SQL Server：sp_who

Q： php 网站的服务器，内存在数天内缓慢上升

A： 大概是 php-fpm 占用过多，或进程数太多

更改 php 的配置（如 max_spare_servers），执行：service php-fpm reload

Q： 进程 cloudfs 占用内存过多

A： 参：https://xoyozo.net/Blog/Details/cloudfs-cache

Q： RDS 磁盘占用过大

A： 参：https://xoyozo.net/Blog/Details/how-to-use-rds

Q： ECS 受到 DDoS 攻击怎么办？

A： 参：https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp

Q： 如果 ECS 和 RDS 各项指标都没有异常，但网页打开慢或打不开502，TTFB 时间很长，是什么原因？（ECS 的 CPU 100%，RDS 的连接数上升，也可参考此条）

A： 数据库有坏表，尝试优化/修复表（慢 SQL 日志中锁等待时间较长的表？），或主备切换。show full processlist 时看到许多

DELETE FROM pre_common_session WHERE  sid='******'  OR lastactivity<******  OR (uid='0' AND ip1='*' AND ip2='*' AND ip3='*' AND ip4='*' AND lastactivity>******)

Q： Discuz! 创始人(站长)密码被改

A： 数据库找到 pre_ucenter_members 表，复制其它的已知登录密码的账号，复制其 password 和 salt 两个字段的值到创始人账号中，创始人账号即可用该密码登录了。

Q： 通过 iftop 观察到，Discuz! 网站从 RDS 数据库到 ECS 网站服务器私网流量非常大，远大于公网流量

A： 可能是缓存出问题了，尝试卸载重装 Redis 来解决。

Q： 宝塔面板中安装的 Redis 经常自动停止

A： 尝试卸载重装 Redis 来解决。

Q： 马甲客户端出现“您的网络有些问题”

A： 原因有许多，其中一个就是新建了一个数据表，然后 /source/class/table/ 下面丢失了对应的文件，具体可以找官方排查原因。

Q： 排查服务器安全需要检查哪些日志？

A： Web日志、登录日志（/var/log/secure）等。

Q： 带宽波形以几分钟为周期呈锯齿状波动是什么原因？

A： 该现象主要由防火墙流量管控机制与检测周期设置共同作用所致。防火墙基于预设的带宽阈值执行安全防护策略，当检测到流量峰值超过设定阈值时，将自动触发限流策略拒绝后续请求。待流量回落至安全阈值后，系统自动恢复服务访问权限。若防火墙的带宽采样检测周期设置过长（如以分钟为单位的检测间隔），将导致系统对实时流量变化的响应出现迟滞。这种周期性的检测机制会使带宽监控数据在阈值临界点附近呈现规律性的锯齿状波动特征。

优化建议：可通过调整防火墙的流量检测周期至更小时间粒度（如10-15秒），或采用动态流量整形策略，以实现更平滑的带宽控制效果。

补充说明：对于阿里云监控数据的调用，建议注意接口调用频率管控。高频调用云监控API接口将触发阿里云的API计费策略，可能产生额外的资源消耗成本。

其它案例

1. 某台 ECS 上的多个网站出现 502，查询到 CPU / 内存 / 带宽 都比平时高，但都未满。用 iftop 看到连接的一个远程 Redis 占用内网带宽非常高。尝试重启远程 Redis 未果。尝试重启 ECS 上的 nginx 未果。尝试重启 ECS 未果。进入 ECS 的宝塔面板，重启 PHP 有效。

把选中的座位按并排分组后，每组座位的：

两侧都有且仅有一个空位时，往影院中央移一座；

一侧有且仅有一个空位，另一侧有连续的大于1个空位时，往仅有一个空位一侧移一座；

其它情况不移动。

 

逻辑实现时须注意：

在判断某组时，其它组中的座位视为已售；

循环组时应优先判断远离影院中央的座位组，这样可以尽可能地往中央移座；

循环中一旦遇到移座情况，应重新分组优化选座。

wxy0510：经过用户表优化后，论坛不活跃用户将被转至存档表。这将意味着论坛在常规调用、查询都不会遍历这些存档表的数据。这也大大提高服务器工作效率，减少服务器负载。当然处于存档表的用户在执行一次登录操作后，数据会重新转入主表。

xoyozo：这个登录是指论坛本身的用户登录，如果用第三方客户端 App 登录一般是不起作用的（除非 App 考虑到了这个情况）

common_member 是主表，common_member_archive 是存档表，这两个表的用户数相加即为 UC 用户表 ucenter_members 中的用户总和。

准备：

先把超时时间改成 300 秒，参 http://www.cnblogs.com/jackluo/p/3366612.html

了解一下分表基本原理：http://www.discuz.net/thread-2132691-1-1.html

 

主题分表：
    可以任意创建主题存档表（forum_thread_X）
    使用“主题移动”功能，筛选符合条件的主题，移动到主题存档表
    新发表的主题仍然存于原始表（forum_thread）
    移动到存档表中的主题，会在主题所在的版块下建立一个存档区，通过存档区可浏览存档表中的主题。
    存档表中的主题，只供浏览，不可回复、评分，不能进行管理操作，但可以删除和移动到非存档区。

帖子分表：
    帖子没有存档的概念
    可以任意创建帖子分表（分表时创建新表或选择已存在分表）
    一次分表操作可移动100MB的整数倍数据
    根据主题表中最后回复时间正序排列的主题（first=1）tid 来获取帖子数据的
    并将该主题的所有帖子移到目标表中
    更新主题表中 posttableid 这个字段，来标识帖子的存储表

关闭论坛
关闭论坛监控
关闭数据库自动备份
主题先不分
第一个 100MB 用了 75 分钟，后来发现问题，数据库恢复了一下
然后1G用了1个半小时，估计恢复的时候顺便“优化”了

转移后打开帖子提示“没有找到帖子”，或者优化后打开帖子提示“没有找到帖子”，只要在数据库里“修复”一下就行了。（在Navicat“对象”中选中所有表，右键分析）

微信是一个生活方式，朋友圈是用户分享和关注朋友们生活点滴的空间，微信公众平台是一个企业、机构与个人用户之间交流和服务的平台。一直以来，微信致力于为用户提供绿色、健康的网络生态环境。通过《微信公众平台服务协议》、《微信公众平台运营规范》和《微信开放平台开发者服务协议》等相关协议及专项规则，微信公众平台和微信开放平台的内容得到了良好的管理。为了进一步优化微信用户的使用体验，更好地保障微信用户合法权益，现将非由微信公众平台产生（即域名地址不归属于微信公众平台）且在微信内传播的外部链接内容相关管理规范进行公示。

对于违反本规范的内容，一经发现将立即进行处理，包括但不限于停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行访问、屏蔽相关链接等。由微信公众平台或开放平台帐号施行或者发起的，一经查实，前述帐号、主体也将按照微信相关规则进行处罚，包括但不限于限制或禁止使用部分或全部功能、帐号封禁直至注销等，并公告处理结果；微信也有权依照本规范及相关协议、专项规则的规定，拒绝再向前述主体提供服务。

具体规则及相关处罚如下：

1. 诱导分享类内容

   1. 1.1 要求用户分享，分享后方可进行下一步操作，分享后方可知道答案等；

   2. 1.2 含有明示或暗示用户分享的文案、图片、按钮、弹层、弹窗等的，如：分享给好友、邀请好友一起完成任务等；

   3. 1.3 通过利益诱惑，诱导用户分享、传播外链内容或者微信公众帐号文章的，包括但不限于：现金奖励、实物奖品、虚拟奖品（红包、优惠券、代金券、积分、话费、流量、信息等）、集赞、拼团、分享可增加抽奖机会、中奖概率，以积分或金钱利益诱导用户分享、点击、点赞微信公众帐号文章等；

   4. 1.4 用夸张言语来胁迫、引诱用户分享的。包括但不限于：“不转不是中国人”、“请好心人转发一下”、“转发后一生平安”、“转疯了”、“必转”、“转到你的朋友圈朋友都会感激你”等；

      

      

      若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问，短期封禁相关开放平台帐号或应用的分享接口；对于情节恶劣的情况，永久封禁帐号、域名、IP地址或分享接口。 

2. 诱导关注类内容

   1. 强制或诱导用户关注公众帐号的，包括但不限于关注后查看答案、领取红包、关注后方可参与活动等；

      

      若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。 

3. H5游戏、测试类内容

   1. 以游戏、测试等方式，吸引用户参与互动的，具体形式包括但不限于比手速、好友问答、性格测试，测试签、网页小游戏等；

      

      

      若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。 

4. 欺诈类内容

   1. 4.1 虚假红包、活动

      通过虚假的红包、活动等形式，以赚取现金、实物奖品、虚拟奖品等方式欺骗用户参与的，具体形式包括但不限于虚假现金红包、虚假话费卡、虚假流量红包、虚假优惠券、虚假优惠活动等； 

   2. 4.2 宣传或销售侵害他人合法权益的商品

      通过虚假宣传、恶意营销等方式，向用户宣传或诱骗用户购买侵害他人合法权益的物品的，例如以骗取邮费为目的的赠送物品活动、虚假付费服务等； 

   3. 4.3 仿冒微信公众帐号排版、域名

      仿冒微信公众帐号文章排版、域名，可能造成微信用户混淆的；

      

      若内容中包含以上情况，一经发现，立即永久封禁帐号、域名、IP地址。 

5. 谣言类内容

   1. 发送不实信息，制造谣言，可能对他人、企业或其他机构造成损害的，例如自来水有毒、香蕉致癌、小龙虾不能吃等；

      

      若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问、短期封禁相关开放平台帐号或应用的分享接口；对于情节恶劣的情况，永久封禁帐号、域名、IP地址； 

6. 骚扰信息、广告信息及垃圾信息

   1. 传播骚扰、欺诈、垃圾广告等信息的，包括但不限于虚假中奖类信息，不符合国家相关法律法规的保健品、药品、食品类信息，假冒伪劣商品信息，虚假服务信息，虚假网络货币等；

   2. 若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。 

7. 题文不符、内容低俗的信息

   1. 7.1 题文不符的信息

      故意拟制耸动标题，或以明显倾向性、误导性、煽动性的标题吸引他人点击的，即俗称“标题党”； 

   2. 7.2 内容低俗的信息

      涉及性器官、性行为、性暗示的，传播低级趣味、庸俗、有伤风化内容的，或者宣扬暴力、恶意谩骂、侮辱他人内容的，例如：传播走光、偷拍、露点、一夜情、换妻、性虐待、情色动漫、非法性药品广告和性病治疗广告、推介淫秽色情网站等；

      

      若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。 

8. 非法获取用户数据、信息

   1. 未经用户明确同意，并向用户如实披露数据用途、使用范围等相关信息的情形下复制、存储、使用或传输用户数据的，包括但不限于要求用户共享个人信息（手机号、出生日期等）才可使用其功能，或收集用户密码或者用户个人信息（包括但不限于，手机号，身份证号，生日，住址等）；

   2. 若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问，短期封禁相关帐号；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。

9. 其它违反国家法律法规的内容，包括但不限于：

   1. (1) 违反宪法确定的基本原则的；

   2. (2) 危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一的；

   3. (3) 损害国家荣誉和利益的；

   4. (4) 煽动民族仇恨、民族歧视，破坏民族团结的；

   5. (5) 破坏国家宗教政策，宣扬邪教和封建迷信的；

   6. (6) 散布谣言，扰乱社会秩序，破坏社会稳定的；

   7. (7) 散布淫秽、色情、赌博、暴力、恐怖或者教唆犯罪的；

   8. (8) 侮辱或者诽谤他人，侵害他人合法权益的；

   9. (9) 煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；

   10. (10) 以非法民间组织名义活动的；

   11. (11) 含有法律、行政法规禁止的其他内容的。

   12.  

       若内容中包含以上情况，一经发现，立即停止链接内容在朋友圈继续传播、停止对相关域名或IP地址进行的访问，短期封禁相关帐号；对于情节恶劣的情况，永久封禁帐号、域名、IP地址。

申诉及常见问题可查看：http://kf.qq.com/faq/131117ne2MV7141117JzI32q.html

微信团队请用户主动遵守上述条款，也欢迎用户对违反微信链接类内容管理规范的内容进行投诉，一经核实，微信团队将立即按照规范进行处理。让我们共同创建并维护和谐的微信生态！

 

微信团队

编者按：今天腾讯万技师同学的这篇技术总结必须强烈安利下，目录清晰，层次分明，每个接口都有对应的简介、系统要求、实例、核心代码以及超实用的思维发散，帮你直观把这些知识点get起来。以现在HTML 5的势头，同志们，你看到的这些，可都是钱呐。

十二年前，无论多么复杂的布局，在我们神奇的table面前，都不是问题；

十年前，阿捷的一本《网站重构》，为我们开启了新的篇章；

八年前，我们研究yahoo.com，惊叹它在IE5下都表现得如此完美；

六年前，Web标准化成了我们的基础技能，我们开始研究网站性能优化；

四年前，我们开始研究自动化工具，自动化测试，谁没玩过nodejs都不好意思说是页面仔；

二年前，各种终端风起云涌，响应式、APP开发都成为了我们研究的范围，CSS3动画开始风靡；

如今，CSS3动画、Canvas、SVG、甚至webGL你已经非常熟悉，你是否开始探寻，接下来，我们可以玩什么，来为我们项目带来一丝新意？

没错，本文就是以HTML5 Device API为核心，对HTML5的一些新接口作了一个完整的测试，希望能让大家有所启发。

目录：

一、让音乐随心而动 – 音频处理 Web audio API
二、捕捉用户摄像头 – 媒体流 Media Capture
三、你是逗逼？ – 语音识别 Web Speech API
四、让我尽情呵护你 – 设备电量 Battery API
五、获取用户位置 – 地理位置 Geolocation API
六、把用户捧在手心 – 环境光 Ambient Light API
七、陀螺仪 Deviceorientation
八、Websocket
九、NFC
十、震动 - Vibration API
十一、网络环境 Connection API

一、让音乐随心而动 – 音频处理 Web audio API

简介：

Audio对象提供的只是音频文件的播放，而Web Audio则是给了开发者对音频数据进行分析、处理的能力，比如混音、过滤。

系统要求：

ios6+、android chrome、android firefox

实例：

http://sy.qq.com/brucewan/device-api/web-audio.html

核心代码：

var context = new webkitAudioContext();
var source = context.createBufferSource();   // 创建一个声音源
source.buffer = buffer;   // 告诉该源播放何物 
createBufferSourcesource.connect(context.destination);   // 将该源与硬件相连
source.start(0); //播放

技术分析：

当我们加载完音频数据后，我们将创建一个全局的AudioContext对象来对音频进行处理，AudioContext可以创建各种不同功能类型的音频节点AudioNode，比如

1、源节点（source node）

我们可以使用两种方式加载音频数据：
<1>、audio标签

var sound, audio = new Audio();
audio.addEventListener('canplay', function() {
 sound = context.createMediaElementSource(audio);
 sound.connect(context.destination);
});
audio.src = '/audio.mp3';

<2>、XMLHttpRequest

var sound, context = createAudioContext();
var audioURl = '/audio.mp3'; // 音频文件URL
var xhr = new XMLHttpRequest();
xhr.open('GET', audioURL, true);
xhr.responseType = 'arraybuffer'; 
xhr.onload = function() {
 context.decodeAudioData(request.response, function (buffer) {
 source = context.createBufferSource();
 source.buffer = buffer;
 source.connect(context.destination);
 }
}
xhr.send();

2、分析节点（analyser node）

我们可以使用AnalyserNode来对音谱进行分析，例如：

var audioCtx = new (window.AudioContext || window.webkitAudioContext)();
var analyser = audioCtx.createAnalyser();
analyser.fftSize = 2048;
var bufferLength = analyser.frequencyBinCount;
var dataArray = new Uint8Array(bufferLength);
analyser.getByteTimeDomainData(dataArray);

function draw() {
 drawVisual = requestAnimationFrame(draw);
 analyser.getByteTimeDomainData(dataArray);
 // 将dataArray数据以canvas方式渲染出来
};

draw();

3、处理节点（gain node、panner node、wave shaper node、delay node、convolver node等）

不同的处理节点有不同的作用，比如使用BiquadFilterNode调整音色（大量滤波器）、使用ChannelSplitterNode分割左右声道、使用GainNode调整增益值实现音乐淡入淡出等等。

需要了解更多的音频节点可能参考：
https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API

4、目的节点（destination node）

所有被渲染音频流到达的最终地点

思维发散：

1、可以让CSS3动画跟随背景音乐舞动，可以为我们的网页增色不少；
2、可以尝试制作H5酷酷的变声应用，增加与用户的互动；
3、甚至可以尝试H5音乐创作。

看看google的创意：http://v.youku.com/v_show/id_XNTk0MjQyNDMy.html

二、捕捉用户摄像头 – 媒体流 Media Capture

简介：

通过getUserMedia捕捉用户摄像头获取视频流和通过麦克风获取用户声音。

系统要求：

android chrome、android firefox

实例：

捕获用户摄像头 捕获用户麦克风

http://sy.qq.com/brucewan/device-api/camera.html

http://sy.qq.com/brucewan/device-api/microphone-usermedia.html

核心代码：

1、摄像头捕捉

navigator.webkitGetUserMedia ({video: true}, function(stream) {
 video.src = window.URL.createObjectURL(stream);
 localMediaStream = stream;
}, function(e){

})

2、从视频流中拍照

btnCapture.addEventListener('touchend', function(){
	if (localMediaStream) {
		canvas.setAttribute('width', video.videoWidth);
		canvas.setAttribute('height', video.videoHeight);
		ctx.drawImage(video, 0, 0);
	}
}, false);

3、用户声音录制

navigator.getUserMedia({audio:true}, function(e) {
	context = new audioContext();
	audioInput = context.createMediaStreamSource(e);	
	volume = context.createGain();
	recorder = context.createScriptProcessor(2048, 2, 2);
	recorder.onaudioprocess = function(e){
		recordingLength += 2048;
		recorder.connect (context.destination); 
	}	
}, function(error){});

4、保存用户录制的声音

var buffer = new ArrayBuffer(44 + interleaved.length * 2);
var view = new DataView(buffer);
fileReader.readAsDataURL(blob); // android chrome audio不支持blob
… audio.src = event.target.result;

思维发散：

1、从视频拍照自定义头像；
2、H5视频聊天；
3、结合canvas完成好玩的照片合成及处理；
4、结合Web Audio制作有意思变声应用。

三、你是逗逼？ – 语音识别 Web Speech API简介：

1、将文本转换成语音；
2、将语音识别为文本。

系统要求：
ios7+，android chrome，android firefox

测试实例：

http://sy.qq.com/brucewan/device-api/microphone-webspeech.html

核心代码：

1、文本转换成语音，使用SpeechSynthesisUtterance对象；

var msg = new SpeechSynthesisUtterance();
var voices = window.speechSynthesis.getVoices();
msg.volume = 1; // 0 to 1
msg.text = ‘识别的文本内容’;
msg.lang = 'en-US';
speechSynthesis.speak(msg);

2、语音转换为文本，使用SpeechRecognition对象。

var newRecognition = new webkitSpeechRecognition();
newRecognition.onresult = function(event){
	var interim_transcript = ''; 
	for (var i = event.resultIndex; i < event.results.length; ++i) {
		final_transcript += event.results[i][0].transcript;
	}
};

测试结论：

1、Android支持不稳定；语音识别测试失败（暂且认为是某些内置接口被墙所致）。

思维发散：

1、当语音识别成为可能，那声音控制将可以展示其强大的功能。在某些场景，比如开车、网络电视，声音控制将大大改善用户体验；
2、H5游戏中最终分数播报，股票信息实时声音提示，Web Speech都可以大放异彩。

 四、让我尽情呵护你 – 设备电量 Battery API简介：

查询用户设备电量及是否正在充电。

系统要求：

android firefox

测试实例：

http://sy.qq.com/brucewan/device-api/battery.html

核心代码：

var battery = navigator.battery || navigator.webkitBattery || navigator.mozBattery || navigator.msBattery;
var str = '';
if (battery) {
 str += '<p>你的浏览器支持HTML5 Battery API</p>';
 if(battery.charging) {
 str += '<p>你的设备正在充电</p>';
} else {
 str += '<p>你的设备未处于充电状态</p>';
}
 str += '<p>你的设备剩余'+ parseInt(battery.level*100)+'%的电量</p>';
} else {
 str += '<p>你的浏览器不支持HTML5 Battery API</p>';
}

测试结论：

1、QQ浏览器与UC浏览器支持该接口，但未正确显示设备电池信息；
2、caniuse显示android chrome42支持该接口，实测不支持。

思维发散：

相对而言，我觉得这个接口有些鸡肋。
很显然，并不合适用HTML5做电池管理方面的工作，它所提供的权限也很有限。
我们只能尝试做一些优化用户体验的工作，当用户设备电量不足时，进入省电模式，比如停用滤镜、摄像头开启、webGL、减少网络请求等。

 五、获取用户位置 – 地理位置 Geolocation简介：

Geolocation API用于将用户当前地理位置信息共享给信任的站点，目前主流移动设备都能够支持。

系统要求：

ios6+、android2.3+

测试实例：

http://sy.qq.com/brucewan/device-api/geolocation.html

核心代码：

var domInfo = $("#info");

// 获取位置坐标
if (navigator.geolocation) {
	navigator.geolocation.getCurrentPosition(showPosition,showError);
}
else{
	domInfo.innerHTML="抱歉，你的浏览器不支持地理定位！";
}

// 使用腾讯地图显示位置
function showPosition(position) {
	var lat=position.coords.latitude;
	var lon=position.coords.longitude;

	mapholder = $('#mapholder')
	mapholder.style.height='250px';
	mapholder.style.width = document.documentElement.clientWidth + 'px';

	var center = new soso.maps.LatLng(lat, lon);
	var map = new soso.maps.Map(mapholder,{
		center: center,
		zoomLevel: 13
	});

	var geolocation = new soso.maps.Geolocation();
	var marker = null;
	geolocation.position({}, function(results, status) {
		console.log(results);
		var city = $("#info");
		if (status == soso.maps.GeolocationStatus.OK) {
			map.setCenter(results.latLng);
			domInfo.innerHTML = '你当前所在城市: ' + results.name;
		if (marker != null) {
			marker.setMap(null);
		}
		// 设置标记
		marker = new soso.maps.Marker({
			map: map,
			position:results.latLng
		});
		} else {
			alert("检索没有结果，原因: " + status);
		}
	});
}

测试结论：

1、Geolocation API的位置信息来源包括GPS、IP地址、RFID、WIFI和蓝牙的MAC地址、以及GSM/CDMS的ID等等。规范中没有规定使用这些设备的先后顺序。
2、初测3g环境下比wifi环境理定位更准确；
3、测试三星 GT-S6358(android2.3) geolocation存在，但显示位置信息不可用POSITION_UNAVAILABLE。

六、把用户捧在手心 – 环境光 Ambient Light简介：

Ambient Light API定义了一些事件，这些时间可以提供源于周围光亮程度的信息，这通常是由设备的光感应器来测量的。设备的光感应器会提取出辉度信息。

系统要求：

android firefox

测试实例：

http://sy.qq.com/brucewan/device-api/ambient-light.html

核心代码：

这段代码实现感应用前当前环境光强度，调整网页背景和文字颜色。

var domInfo = $('#info');
if (!('ondevicelight' in window)) {
	domInfo.innerHTML = '你的设备不支持环境光Ambient Light API';
} else {
	var lightValue = document.getElementById('dl-value');
	window.addEventListener('devicelight', function(event) {
		domInfo.innerHTML = '当前环境光线强度为：' + Math.round(event.value) + 'lux';
		var backgroundColor = 'rgba(0,0,0,'+(1-event.value/100) +')';
		document.body.style.backgroundColor = backgroundColor;
		if(event.value < 50) {
			document.body.style.color = '#fff'
		} else {
			document.body.style.color = '#000'
		}
	});
}

思维发散：

该接口适合的范围很窄，却能做出很贴心的用户体验。

1、当我们根据Ambient Light强度、陀螺仪信息、当地时间判断出用户正躺在床上准备入睡前在体验我们的产品，我们自然可以调整我们背景与文字颜色让用户感觉到舒适，我们还可以来一段安静的音乐，甚至使用Web Speech API播报当前时间，并说一声“晚安”，何其温馨；

2、该接口也可以应用于H5游戏场景，比如日落时分，我们可以在游戏中使用安静祥和的游戏场景；

3、当用户在工作时间将手机放在暗处，偷偷地瞄一眼股市行情的时候，我们可以用语音大声播报，“亲爱的，不用担心，你的股票中国中车马上就要跌停了”，多美的画面。

参考文献：
https://developer.mozilla.org/en-US/docs/Web/API
http://webaudiodemos.appspot.com/
http://www.w3.org/2009/dap/