问题假设有256M内存，要对一个有10G数据文件进行排序

思路： 先分治，再归并。
步骤1：把文件根据内存大小进行拆分为若干小文件，具体大小保证小于排序所需要的内存，并排序。
步骤2：合并有序小文件。
如何合并呢？ 取每个文件的第一个元素进行比较，最小值就是所有元素中最小的，放到大文件。下一轮再拿第二个，以此类推...
步骤2其实是N个数找最小值问题，原始方法时间复杂度较高，可以用更优的算法替换。

MySQL字符串最主要的类型是varchar和char。

varchar 用于存储可变长字符串，比定长节省空间。原理是使用1或2个额外字节记录字符串的长度：列长小于等于255字节，则用1字节表，否则用2字节。例如varchar(10)的列的存储空间为11字节，varchar(1000)的列则需要1002字节。

但是由于变长的，在update时会做额外的工作。

合适的场景：字符串列的最大长度比平均长度大很多；列更新较少；使用了像UTF-8这样复杂的字符集，每个字符都使用不同的字节数进行存储。

char 是定长的，MySQL 会删除所有的末尾空格。

合适的场景：很短的字符串，或者所有值接近同一个长度。如MD5值。经常更新的列char不容易产生碎片。定长的列最好用char，如身份证，手机号

长度限制：

char：最大长度为255，超过这个数值会提示：

MySQL said: Column length too big for column 'char' (max = 255); use BLOB or TEXT instead

varchar：最大长度与字符集有关：
字符类型若为gbk，每个字符最多占2个字节，最大长度不能超过32766;
字符类型若为utf8，每个字符最多占3个字节，最大长度不能超过21845。
使用utf-8mb4字符集，一个字符占用4个字节，最大长度是(65535-2)/4=16383 个字符。
若定义的时候超过上述限制，则varchar字段会被强行转为text类型，并产生warning。

text：变长，最大长度65535字节。没有默认值。
mediumtext：最大长度16777215(2^24-1)字节。
longtext：最大长度2147483647(2^31-1)字节。

总结：varchar可变长，用额外1个或2个字节存储长度，节省空间；char定长，没有额外操作，更适合短且定长的列。

linux 性能监控的指标包括：

CPU、内存、IO、网络等等。

这些子系统之间关系是相互彼此依赖的,任何一个高负载都会导致其他子系统出现问题.比如:
大量的页调入请求导致内存队列的拥塞
网卡的大吞吐量可能导致更多的 CPU 开销
大量的CPU 开销又会尝试更多的内存使用请求
大量来自内存的磁盘写请求可能导致更多的 CPU 以及 IO 问题
所以要对一个系统进行优化,查找瓶颈来自哪个方面是关键,虽然看似是某一个子系统出现问题,其实有可能
是别的子系统导致的.

- 阅读剩余部分 -

explain工具用来查看SQL执行计划，多用来优化索引，关键要了解它返回字段的含义。其中最主要的信息在type和extra列。

- 阅读剩余部分 -

事务

InnoDB的事务符合ACID特性：

• 原子性 atomicity
• 一致性 consistency
• 隔离性 i
• 一致性 d

事务通过redo log(重做日志)和 undo log(回滚日志)实现。
redolog保证事务的原子性和持久性，undolog保证事务的一致性。redolog是物理操作，记录页的修改操作，undolog是逻辑日志，根据每行记录进行记录。

- 阅读剩余部分 -

show profiles;
// 查看查询信息show profile for query 3;
// 查具体queryid 的detail随着偏移量增大，sending data 时间越大
https://blog.csdn.net/it_r00t/article/details/85116530

InnoDB 事务性引擎，被设计用来处理大量短期事务。
类型：事务性
场景：处理大量短期事务
特性：自动崩溃恢复特性
InnoDB采用MVCC来支持高并发，表基于聚簇索引来建立，聚簇索引对主键查询有很高的性能，不过它的二级索引（非主键索引）都要包含主键列，所以如果主键列很大的话，其他索引也会很大。所以表中的索引很多的话，尽可能主键小。 InnoDB内部优化，磁盘读取数据的可预测读取，在内存自动创建hash索引来加速读操作的自适应hash索引，加速插入操作的插入缓冲区。 热备份，是其他引擎不具备的。

MyISAM
特性：全文索引，压缩，空间函数（GIS） 加锁与并发，MyISAM对表加锁，不是对行，读时对表加共享锁，写时加排它锁。 压缩表，表创建后不再修改，可压缩，好处是减少磁盘空间，减少磁盘I/O,提升查询性能。

Archive 只支持查询和插入。 缓存所有的写利用zlib压缩，节省磁盘空间，但是每次select都要全表扫描，所以适用于日志和数据采集类应用 Archive支持行级锁和缓冲区，可以实现高并发的插入；在一个查询开始直到返回表中存在的所有行数之前，会阻止其他select。

blackhole 问题较多，不推荐

CSV 将CSV文件作为表操作，CSV时逗号分隔值的文件，不支持索引，常用于数据交换。

Memory 在内存中，重启后表结构还在，数据会丢失。速度很快，使用场景：查找或映射、缓存周期性聚合数据、保存中间数据。 支持hash索引，支持表级锁，因此并发写入的性能较低

背景：想将php5.6升级到7 步骤： 由于php5.6是Mac自带的，所以没有管它，通过homebrew安装php7，这个自己上网找就行，有很多。

问题： 安装完7.0后不知如何与nginx配置，命令php -v 查看的PHP版本是7.0，通过nginx的phpinfo()显示的还是5.6。所以一定是nginx的配置问题。

解决过程： 找到问题所在位置，nginx通过ip+端口号访问php-fpm，在nginx.conf中是php-fpm中监听的端口，我是将原来的php-fpm中的9000改成9001，这样nginx默认访问php70-fpm，在访问phpinfo()就是7.0。

注意： 重启php70-fpm之前要kill php-fpm，命令killall php-fpm，sudo /usr/local/sbin/php70-fpm restart 找不到php-fpm所在路径的话，可通过php-fpm -t 查看。

材料：草料二维码生成器，长度为95的链接
场景：生成的二维码没有问题，直接扫可以访问；当用canvas合成压缩后二维码时好时坏。考率过长度、分辨率、过尝试了几次发现规律，链接过长有问题，链接较短则没问题，原因是链接过长导致二维码图案过于密集，压缩会出现问题。
最后使用微博短链接工具，将链接转换为短链接，得以解决。