show variables like 'event%'; 查看event_scheduler是否开启
set global event_scheduler =1; 开启事件计划
创建存储过程
1 | create procedure test() |
创建事件（每隔30s执行存储过程test）
1 | create event if not exists e_test |
本文主要内容来自火币资讯区块链100问科普摘录，方便自己翻阅，仅供参考
莱特币的宗旨是改进比特币，所以它和比特币有很多相似之处。
莱特币总量是比特币的四倍，8400万枚；它的产量减半时间和比特币一样都是4年；它的共识机制和比特币一样都是工作量证明机制（PoW）；它的区块时间是2.5分钟，是比特币的四分之一，每2.5分钟打包一个区块；莱特币的区块奖励最早是50枚莱特币，截止目前（2018年1月）莱特币区块奖励为25莱特币，已发行量约为5400万。
###
很多业务都有分页获取信息列表的需求，在数据量、读写负载都不大的情况下，不需要分库分表。但是在大型流量和负载量面前，是需要进行分库分表来缓解数据库的存储压力的。上次Jeri老师提到思考分表时如何处理分页查询的问题，就思考了几个解决方案，同时查阅了一些文章，目前还在完善中…
比如淘宝上面的商品，有很多排序的维度，比如价格、好评、销量等。但是数据库的表往往是有一个与业务字段无关的主键id作为记录的唯一标识，且默认从数据库中取出数据是按主键id排序的，但业务中的场景要求我们根据其它字段来排序。单表的话只需要在排序字段上建立索引，通过limit就可以完成分页查询需求。
1 | SELECT * FROM product ORDER BY price offset 20 limit 10; |
大流量、数据量的项目，随着数据量增大，需要将数据库进行水平切分来达到扩容的目的。一般水平分表时，采用的partition key都是主键id。为了保证负载均衡和数据量均衡，可以采用id取模或者做一次hash再取模来分库，这也是必要常用的实现负载均衡的方式，我观察了一下，“联名卡”项目的分表就是直接对主键进行取模，不过有几个表主键不是简单递增的，可能直接取模就不是最好的均衡的手段，我觉得可以做一个随机性高的hash再取模。
举个需求例子，从这个例子开始谈方案。比如商品列表查询，通过主键id取模分了3个表，但查询时有“价格从低到高”的需求，每页十条数据。问题就来了：解决水平分表，且分库key与排序key不同的分页查询需求。
比如要按照价格从低到高取第三页的数据，为保证数据准确性，需要考虑极端情况：价格从高到低的前三页数据都来自于其中一张分表。但正常情况是前三页数据可能在每个表的前三页里都取数据，所以需要每个表都取三页数据出来，在内存中进行类似归并的排序，排序后再进行单表类似的简单查询，假设每页10条数据，
步骤
每个表都取出前三页的数据
1 | SELECT * FROM product ORDER BY price offset 0 limit 30; |
各个分表执行这条SQL，业务层将得到90条数据
业务代码对这90条数据进行排序，排序后再取offset 20 limit 10的数据
优点
缺点
这个方案是我不确定能否实践的想法，这里选择用redis而不是关系型数据库是因为性能的考虑，不过我认为redis这块可能会存在可用性问题。
| id | price | table_no |
|---|---|---|
| 12 | 80 | 1 |
| 6 | 100 | 3 |
| 3 | 102 | 1 |
| 7 | 104 | 2 |
| 54 | 120 | 2 |
很多时候业务上进行一下折衷可以降低很多开发难度（要看能不能怼过PM了）。我们可以发现，现在我们日常浏览很多的信息流产品，并没有指定页跳转，而是下滑刷新。首先这也是业务上的特点，信息流产品的用户主要功能为浏览，对于跳页的需求不高，所以这里去掉指定页跳转没有问题。这里就有一个不错的方案，可以解决第一个方案的传输量过大的问题，我称他为“设置锚点”。
步骤
对于每个分表的查询语句为，初始时min变量为0，因为价格都大于0
1 | SELECT * FROM product ORDER BY price where price > $min limit 10; |
三个表一共取出30条数据，在内存中进行归并排序，再取出结果中的前10条，完成第一页查询。记录结果中的最后一条，作为下一页查询的初始锚点，即变量min。
下滑刷新，即获取下一页数据时，把min代入，继续执行第一步中的SQL，同样只接受30条数据，就完成了第二页的查询，之后无论多少“下一页”都是固定的数据量：分表数*单页数据量
优点：查询性能有保证，不会根据分表数和页数的增加而大量占用带宽。
缺点：需要业务折衷，商品、信息流适用，管理系统不一定适用。
从网上的技术文章学习到了一个终极武器：二次查询法。在此自己梳理一下，假设每页需要5个数据，要查第19页的数据。感觉语言描述不是很清楚，之后做几张图出来。
步骤
查询语句改写
1 | # 单表查询时的语句 |
得到三页按照price递增的数据后，比较三页的第一个数据，找到最小的，即使这三页里面的最小数据，记为min
第二次查询，所有分表执行，max_n为第二步得到的n页数据中分别的最大数据。
1 | SELECT * FROM product ORDER BY price WHERE price between $min and $max_n; |
对于min所在表之外的两张表，查询条件事实上是放宽了，会得到更多的数据。
在每个结果集中虚拟一个min记录，得到min对应记录全局的offset。假设min确实来自表1，则min在表1中的偏移量为30，第二次查询中，对于表2，min和表2第一次查询的最小项的在第二次查询中序号差为k，那么在表2中min的offset就是30-k1；同理，表3中min的offset为30-k2。所以min的全局offset为30+30-k1+30-k2 = 90-k1-k2
利用全局offset和步骤2得到的结果，为三页数据带上全局offset就可以排序。
优点：实现巧妙；查询量不会激增。
缺点：实现理解有一些难度；数据准确度上有折衷，不能很好的处理极端情况；有一定的需要进行两次数据库查询，性能差一丢丢。
近期在鹅厂实习做后端，使用的是公司自研的C++框架，开发自测属于常说的“远程开发”，需要部署到开发机上测试。也就是说，每次改完代码想要调试，需要同步代码到开发机上编译部署，这样有一个好处就是迫使自己在运行代码之前做更充分的考虑，争取一次完成，在这样的情况下，感觉自己在Linux系统上定位和分析问题的能力有了一些提高，这次选出一个与配置和系统函数相关的Bug，在记录一下分析问题的思路（完全没有泄露任何业务）。
因为一些原因，需要大范围重写项目CGI框架所用的配置文件。每个CGI运行时都会加载所需要的配置，观察log会发现，接口运行时会首先检查硬盘上的配置文件是否有更新，如果有则从文件加载配置，如果没有就直接从缓存中取配置，毕竟缓存读取比文件IO快多了。改完配置文件后，发现怎么跑都跑不同，一直挂在Log上，这种不出现在业务代码上的bug一直都是我觉得最难缠的。
报的错误信息一头雾水，执行的还是框架的运行基础代码，那就进入报错的代码部分看一下：
可以看到报错部分的代码执行的正是上面所说的检查文件是否更新，可以看到这里调用了是一个Linux系统C函数stat，那就再往下一层，看一下这个函数的具体信息，尤其是错误码，在Linux下执行man 2 stat查看Linux手册说明，下面是错误码部分：
梳理需要的关键信息：
stat()和lstat()，需要获得指向目标文件整个路径的执行权限首先文件权限没开执行权限的可能性很大，检查了一下，开得是777，不是权限的问题。
再阅读一下几个错误的描述，文件描述符错误、文件有符号链接问题，存取被拒绝，好像都不是我们会遇到的问题。
相对的其中ENOTDIR的描述就很有趣：文件前缀的路径存在但不是一个真正的路径。这个时候去配置文件夹目录前执行ll，发现配置文件路径是个软链接，会不会就是因为这个函数需要执行在真实路径上的文件而非软链接呢？
尝试修改配置文件路径为真实路径，配置文件正常加载，Debug完成~
之前对于Linux的软硬链接就有点疑问，这次就记录清楚。
Linux通过ln命令来创建软/硬链接，也就是为一个文件在另外一个位置建立一个同步的链接，通常的用法是
1 | ln -s 源文件 目标文件(即链接) |
-s是最常用的参数，它是指软链接，它只会在指定的目标位置上生成一个同步的镜像，并不会占用磁盘空间。硬链接就是不带s参数，它在目标位置生成一个与源文件大小相同的文件。不过硬链接有限制，不能给目录建立硬链接，且只有root才有简历硬链接的权限。
软链接：也叫做“符号链接”，软链接文件有类似于Windows的快捷方式。它实际上是一个特殊的文件。在符号连接中，文件实际上是一个文本文件，其中包含的有另一文件的位置信息。
硬链接：硬连接指通过索引节点来进行连接。在Linux的文件系统中，保存在磁盘分区中的文件不管是什么类型都给它分配一个编号，称为索引节点号(Inode Index)。在Linux中，多个文件名指向同一索引节点是存在的。一般这种连接就是硬连接。硬连接的作用是允许一个文件拥有多个有效路径名，这样用户就可以建立硬连接到重要文件，以防止“误删”的功能。其原因如上所述，因为对应该目录的索引节点有一个以上的连接。只删除一个连接并不影响索引节点本身和其它的连接，只有当最后一个连接被删除后，文件的数据块及目录的连接才会被释放。也就是说，文件真正删除的条件是与之相关的所有硬连接文件均被删除。
在日常的学习开发中，越来越感觉到技术选型的重要性，在这其中，数据库选择占了很大一部分。针对不同的需求场景去选择适合的数据库(关系型or非关系型)就是一个重要的能力了，一直都有听说NoSQL如何如何完爆关系型数据库，真的有那么神奇吗？下面就各类取一个典型，简单分析一下。
扩展性不够好，一旦在迭代过程中有需求要增删改字段，就需要执行修改表结构的语句，而修改期间表是被加锁的，会需要暂停服务。
大数据场景下IO过高，因为关系型数据库采取的是“按行存储”，而大数据处理中很多时候需要的反而是很长一段的单列数据，但是关系型数据库还需要按行把整行数据读取到内存中。
KV数据库里应用最多的就是Redis了，我们知道在实际场景中它更多的被用于内容缓存、访问负载大的场景、Session分离、排行榜、点赞功能，购物车等等。最主要的优点就在于性能，大约可以支持10W左右的TPS(Transactions per second)，支持众多的数据结构，比如Hash，SortedSet，Bitmap，Hyperlog等等。
但是就Redis来说，事务上的ACID特性就不能得到保证了，主要就是A，原子性。Redis是单线程模型，但Redis的普通操作是原子性的，只是Redis事务不支持回滚。也就是说，涉及到一个以上的键去关联数据和需要严格事务支持的场景，是不能选择Redis的。
我自己接触过比较典型的是MongoDB。首先在MongoDB中存储的数据是以JSON的行形势展现，JSON本身是一个可读的强大的描述语言。主要就是解决了关系型数据库在表结构不明确的场景下的无奈。就比如说我们经常会需要的在线填写用户信息，就比如一些职场类网站的个人信息，有很多必填项和选填项且用户可以定制自己的额外信息，在这种场景下，固定的表结构就不好解决这个问题，这也正是文档式数据库的用武之地（当然，你也可以在一个字段里面放一个复杂的JSON，相当于在MySQL里面套了一个文档数据库，解析的性能损耗不言而喻了。）
优点有：字段更改方便，对旧数据兼容，从代码层面处理判空即可，存储信息结构更灵活。缺点也比较明显，如果业务中大量需要多条数据之间的关联查询，单靠MongoDB就不够了。它对于多条数据事务可以说是不支持的。拿ACID来说，事务仅在单文档中保证原子性，且不支持像我们在MySQL那样复杂的join查询。
ElasticSearch应该就是最受欢迎的企业搜索引擎了。它是一个可扩展、开源的全文搜索分析引擎。几乎能实时地进行对大量数据的存储、搜索和分析。海量数据查询的场景就很多了，论坛搜索文章，电商搜索商品都会用到，并且将数据存入ElasticSearch中可以很方便的进行聚合和数据分析的工作。生产上采用的ElasticSearch集群保证了极大的数据容量和可扩展性，是代替关系型数据库全文检索功能的良好解决方案。
最主要的优势就是全文检索的高性能，这个优势的原理是基于“倒排索引”，关于它的介绍之后会单独写一篇文章来详细分析。
HBase是大数据上广泛应用的列式数据库，基于HDFS文件系统，并参考了BigTable文档模型。
它有着很高的存储空间利用率。首先我们可以知道，传统关系型数据库是按行存储的，一行数据各个字段的数据类型一般都会有不同。列式数据库对不同列各自的类型的特征而选择特定的压缩算法使得它有更高的压缩率。普通行式数据库压缩率大概在1/5-1/3左右，列式数据库的压缩率大概在1/30-1/8左右（常用的方式就是字典表压缩）。
在大数据场景需要对一列进行读取时，列式数据库的性能是远远高于行式的，因为一列数据是存储在一起的，一次磁盘IO可以将整列都读取到内存中。
和其它非关系型数据库一样，对于多行数据，它同样不支持多行事务的原子性，也保证不了多行的一致性。且由于按列读取的操作，也不适合频繁的少量行数据读取，不适合做更新和删除的实时操作。
Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.
1 | $ hexo new "My New Post" |
More info: Writing
1 | $ hexo server |
More info: Server
1 | $ hexo generate |
More info: Generating
1 | $ hexo deploy |
More info: Deployment
本文主要内容来自火币资讯区块链100问科普摘录，方便自己翻阅，仅供参考
后端在做上线项目的过程中，是必须要部署生产环境服务器的数据库的，而远程服务器安装又会比本地安装多一些坑（开发远程连接、调整最大连接数等）以及一些简单功能的使用（导入导出数据库），这里就从安装到线上部署的实际用法做一个总结，欢迎补充~
SSH登录服务器后，执行
1 | wget http://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm |
然后安装该yum repository
1 | yum -y install mysql57-community-release-el7-8.noarch.rpm |
在yum仓库中搜索可用的社区版
1 | yum search mysql-com |
选择安装mysql server
1 | yum -y install mysql-community-server.x86_64 |
等待安装完毕后，启动MySQL
1 | systemctl start mysqld |
在每次yum update时都会检查MySQL的版本更新，但大多数时间我们是不需要的，而且这也会影响yum update的速度，可以在安装后移除该yum源yum -y remove mysql57-community-release-el7-8.noarch
首先要登录MySQL服务，我遇到过三种情况
mysql -u root就可以登录root密码是系统自动生成的，被记录在mysql日志中，可以通过cat /var/log/mysqld.log | grep "password"来获取，会看到日志中有一条temporary password，是一个随机串，然后使用mysql -u root -p，copy这个密码登录
没在日志中找到密码，或者忘记密码：首先在配置文件/etc/my.cnf中的[mysqld]下面加上skip-grant-tables，重启服务，这样可以跳过登录验证，然后登录进MySQL后，重置密码，然后回到配置文件去掉那条危险的配置并重启服务
1 | ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password'; |
如果是5.7以上的版本，上面这一条就不适用了，要换成这条
1 | UPDATE mysql.user SET authentication_string=password('your_password') WHERE user='root' AND Host = 'localhost'; |
在设置密码时，如果提示出现Your password does not satisfy the current policy requirements.，说明MySQL5.7后的版本设置了数据库密码安全强度限制，主要是两个全局设置字段:validate_password_policy和validate_password_length，分别是密码复杂度和长度设置，在MySQL中运行两条命令
set global validate_password_policy=0; 设置密码安全级别为LOWset global validate_password_length=4; 设置密码最短长度为4这应该是坑最多的地方了，所以尽量多列几种情况，首先要定位问题
在乱改MySQL配置前，先检查一下防火墙是否允许开放3306端口，或者可以选择关闭防火墙，iptables和firewalld都检查一下
确定防火墙开放后，开始
1 | GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; |
在password中填写你的连接密码，然后一定要刷新权限命令：
1 | FLUSH PRIVILEGES |
如果还是不行，那就本地登录mysql，然后user mysql执行select user,host from user，可以查看现有用户可可以连接的主机，如果只有localhost或者127.0.0.1，就需要走第二步授权新用户访问了，可以指定IP也可以用’%’表示所有主机都可以连接
1 | GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'your_password' WITH GRANT OPTION; |
如果还是不行的话，就可能你用的是Ubuntu版本的，它会在默认的配置里写上只允许本地连接，要修改/etc/mysql/mysql.conf.d/mysqld.cnf里面有一条bind-address: 127.0.0.1把这条配置注释掉重启服务即可。
max_allowed_packet = 20M导出sql和csv：导出SQL比较简单：mysqldump -u root -p dbname [tablename] > dbdump.sql；导出excel表格，使用select ... into outfile例如:
1 | SELECT * FROM article INTO OUTFILE '/tmp/test.csv' |
导入SQL：mysql -u root -p dbname < xxxx.sql