算是对MySQL官方文档对JSON数据类型描述的一个笔记吧！官方介绍在这里：http://dev.mysql.com/doc/refman/5.7/en/json.html。从MySQL 5.7.8开始，MySQL新增了对JSON数据结构的原生支持。JSON数据类型相对于存储JSON格式的字符串的一些优势：1、JSON列会自动验证格式的正确性，错误的JSON会报错。2、优化的存储格式。存储的JSON文档会转换成一个内部的格式，以提供对文档元素的快速访问，当需要访问JSON的某个值得时候，不需要从一个文本里面去解析出这个值。这个二进制结构允许直接查找子对象或者通过key查找嵌套的值，或者是在不需要读取整个数组的情况下查找数组索引。JSON数据类型的最大存储大小是通过系统变量max_allowed_packet来限制的。JSON列不可以有默认值。JSON列不可以被索引。这个限制可以通过生成虚拟列的方法解决，链接：http://dev.mysql.com/doc/refman/5.7/en/create-table.html#create-table-secondary-indexes-vi...
小计一笔，这里仅限是环境搭建的过程。搭了个LNMP的环境，估计很多同学最常遇到的就是502了吧？我搭了那么多次，就是502最多。我遇到的一般都出在用户的设置和目录权限的配置上面的，解决这两点一般就不会有什么问题了。配置nginx，新建了个用户组web，和用户webuser。改配置nginx.conf的user选项为user webuser。执行nginx -t报错：nginx: [emerg] getgrnam("webuser") failed in /etc/nginx/nginx.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed这什么意思啊？一番搜索之后好像没什么有用信息。原来是user www-data，而且系统里面有www-data组和www-data用户。所用猜测报错应该是说用户有问题。nginx检查配置正确性的时候肯定是按照同用户名的组去验证用户的，这里我只写了user webuser。webuser组下面确实没有webuser用户，改成user webuser web一切ok。nginx...
这服务器过期好久了，去后台看了，套餐都不见了，网站竟然还在，还能访问，惊讶。难道是忘记清理了？哈。。。还是去买了个vps来搞搞，之前用的是虚拟主机。昨晚去linode买了个最低配置的主机，新加坡节点，今天起来就搭了个环境，把网站运行起来了。感觉速度还可以啊！嘿嘿！...
原文地址：http://www.innomysql.net/article/21730.htmlInside君整理了一份最新基于MySQL 5.6和5.7的配置文件模板，基本上可以说覆盖90%的调优选项，用户只需根据自己的服务器配置稍作修改即可，如InnoDB缓冲池的大小、IO能力（innodb_buffer_pool_size，innodb_io_capacity)。特别注意，这份配置文件不用修改，可以直接运行在MySQL 5.6和5.7的版本下，这里使用了小小的技巧，具体可看配置文件。如果配置参数存在问题，也可以及时反馈Inside君，我们一起成长。触发Inside君做这件事情的原因是大部分网络上的MySQL配置文件都非常非常古老，大多都是基于MySQL 5.1的版本，这导致了绝大部分MySQL并没有运行在最优的环境，从而导致一些错误的使用，亦或是灾难性事故的发生，比如数据丢失，主从数据不一致等。而这些问题早在5.6版本及以后的版本中得到了解决。最后，抛弃你那所谓的、陈旧的、错误的MySQL配置文件，面向一个崭新的高性能、高可靠、高可扩展MySQL时代，你要做的就是下载这份配置文件...
线性表顺序存储结构是指在内存上用连续的存储空间来存储数据。这就导致这种结构需要在初始化的时候就申请好需要的全部空间。如下图，每一个格子代表一片内存的存储区域，如果我们初始化了一个最大5个元素的顺序存储的线性表，那么它在内存中的存储位置，可能是0,1,2,3,4，也可能只2,3,4,5,6，总之他们的内存地址是连续的。这种结构用完空间之后就没有了，申请多大的空间也不好把握，如果申请的比较大，没有存储数据的空间别的程序也不能使用，只能浪费在哪里了，所以灵活性较小。这种结构和数组很相似，所以可以用数组来实现。Go 代码实现：package main
import (
"fmt"
"errors"
"os"
)
//最大长度
const MAXSIZE = 10
type List struct {
node [MAXSIZE]int //链表节点
len int //链表当前长度
}
func main() {
l := NewList()
for i := 0; i < 9; i++ {
n := i + 1
...
把Mobile Detect类库作为一个组件引入到Yii2里面去。首先需要先用Composer安装Mobile Detect：composer require mobiledetect/mobiledetectlib。然后新建一个DeviceDetect类：<?php
namespace common\service;
use Yii;
use yii\base\Object;
use Detection\MobileDetect;
/**
* 移动设备检测功能
* @link http://mobiledetect.net/
* @link https://www.360us.net/
*
* @example
* //注册一个检测移动设备组件
* Yii::$app->set('deviceDetect', [
* 'class' => 'common\service\DeviceDetect',
* ]);
* //使用
* Yii::$app->deviceDetect->isMobile();
*
* Cl...
mysql的utf8并不是完整的utf8，只能存储最多三个字节的字符，而完整的utf8编码是一个字符最多可以占用4个字节的。这就导致一些4个字节的字符不能存进utf8编码的表里面，比如emoji表情符号。mysql5.5.3版本的时候新增了一个新的字符集，叫做utf8mb4，这个就是真正的utf8编码的，也可以直接存储emoji表情符号。utf8mb4的字符范围是包含utf8的，所以，我们可以直接把当前数据库的编码转换成utf8mb4，不会有任何问题。为了避免以后因为字符范围而导致的问题，我们在新建数据库的时候也应该用utf8mb4代替utf8作为默认的字符编码。校验规则的话utf8mb4_general_ci和utf8mb4_unicode_ci都是可以得，mysql默认是前者，前者校验速度较快，后者则更准确一点。那么如何把当前数据库的编码由utf8转换为utf8mb4呢？我们需要下面几步：首先，我们先备份下原来的数据库，是吧？为了保险起见。然后呢！再核对下msyql的版本号，如果版本低于5.5.3的话就先升级一下吧！第三步，修改数据库，表和列，数量少的话可以直接执行sql语句：#修...
1、验证码验证码被认为是对抗CSRF攻击最简洁而有效的防御方法CSRF攻击的过程，往往是在用户不知情的情况下构造了网络请求。而验证码，则强制用户必须与应用交互，才能完成最终请求。因此，在通常情况下，验证码能够很好地遏制CSRF攻击。通常我们不可能在所有地方都加上验证码，所有这个也只能作为一种辅助手段。2、Referer Check就是检查请求的来源，这个还可以用来做图片的防盗链。Referer是由浏览器通过HTTP头来发送的。但是，这个头也不是什么时候都有的，很多情况下都是没有的，还可以通过程序来自定义。这个也只能作为一个辅助手段。3、Anti CSRF Token防御CSRF的主要方法是使用一个Token。CSRF的本质原因就是重要操作的所有参数都能被攻击者猜测到。攻击者只有预测出一个URL的所有参数与参数值，才能成功构造出一个伪造的请求，反之，攻击者无法攻击成功。因此我们可以在每个请求上面新家一个token参数，这个token是随机的，不可预测的，并且只有用户和服务器知晓，不能被第三方获取。提交请求时，服务器只需验证请求中的token是否存在及合法就可以了。Token的几个使用原则...
1、HttpOnlyHttpOnly最早由微软提出，并在IE6中实现，至今已经逐渐成为一个标准。浏览器将禁止页面的javascript访问带有HttpOnly属性的Cookie。严格来说，HttpOnly并非为了对抗XSS，HttpOnly解决的是XSS后的Cookie劫持攻击。PHP设置带HttpOnly属性Cookie的方法是使用自带的setcookie函数：setcookie('PHPSESSID', '79ce945e3bfd1917919e63a7ddbfe385', null, null, null, null, true);最后一个参数是设置httponly属性，执行后服务器会发送如下设置cookie的头：Set-Cookie:PHPSESSID=79ce945e3bfd1917919e63a7ddbfe385; path=/; HttpOnly2、输入检查常见的Web漏洞如XSS、SQL注入等，都要求攻击这构造一些特殊字符，这些特殊字符可能是正常用户不会用到的，所有输入检查就有存在的必要了。输入检查，在很多时候也被用于格式检查。例如网站注册使用的用户名，会被要求只能用字...
1、定位执行效率较低的sql语句通常有两种方法。一种是慢查询日志，用--log-slow-queries[=file_name]启动时，mysql会记录所有执行时间超过long_query_time秒的sql语句的日志文件。 long_query_time参数单位时秒，精度可以精确到微秒，默认情况下管理语句和不使用索引进行查询的语句是不会记录的，如果要记录这两类sql语句可以用--log-slow-admin-statements和log_queries_not_using_indexes来控制。还有一种方法就是使用show processlist命令查看当前mysql在进行的线程，包括线程的状态，是否锁表等，实时的查看sql的执行情况，同时对锁表操作进行优化。2、通过explain分析低效sql的执行计划 explain命令可以获取mysql的执行计划。执行如下命令：EXPLAIN SELECT * FROM `user` WHERE `uid`=1会显示： id: 1
select_type: SIMPLE
table: user
...