"新特新解读 | MySQL 8.0 对 count(*)的优化 新特性解读 | MySQL 8.0 正则替换 新特性解读 | MySQL 8.0 资源组 新特性解读 | MySQL 8.0 Temptable 引擎介绍\n新特性解读 | MySQL 8.0 窗口函数详解\n新特性解读 | MySQL 8.0 json到表的转换\n新特性解读 | MySQL 8.0.16 在组复制中启用成员自动重新加入\n新特性解读 | MySQL 8.0 直方图\n新特性解读 | MySQL 8.0 索引特性1-函数索引\n新特性解读 | MySQL 8.0 索引特性2-索引跳跃扫描\n新特性解读 | MySQL 8.0 索引特性3 -倒序索引\n新特性解读 | MySQL 8.0 索引特性4-不可见索引\n新特性解读 | MySQL 8.0.16 组复制通讯协议的设置\n新特性解读 | MySQL 8."

"MySQL 中的隔离四种隔离级别与锁的关系一直挺模糊的，看了好多文章感觉着都不是很好理解，今天在“爱可生开源社区”看到一篇文章，感觉着挺容易理解的。\nREAD UNCOMMITTED 未提交读，可以读取未提交的数据。\nREAD COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。\nREPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。\nSERIALIZABLE 序列化\n文中主要对 RR 和 RC 两种常用的隔离级别做了不同情况的说明，对于 SERIALIZABLE 序列化 和 READ UNCOMMITTED 未提交读，由于很好理解所以未在文中体现。**对于 RR 和 RC 主要区别是 RR 存在 Gap Lock间隙锁，而RC则没有Gap Lock间隙锁，**所以在互联网中绝大部分是采用 …"

"在MySQL5.7以前，ibdata1文件会逐渐增大（ ibdata1文件包含哪些信息?），非常占用系统空间，特别是一些云数据来说，磁盘非常的贵，想要回收空间，只能进行一次导出和导入操作，来重新生成undo 表空间，从MySQL5.7开始，有了在线回收undo表空间的功能，主要由以下几个参数设置。\ninnodb_undo_directory = . 为undo文件存储路径。如果没有指定默认值(NULL)，则undo表空间则存放到mysql的data目录里(datadir选项)。配置此项可以用undo从ibdata文件里分离出来。单独存储。\ninnodb_undo_logs = 128 (默认值 128）undo rollback segment 回滚段个数，为 innodb_rollback_segments 参数选项的别名，最大值为128，其中32个为使用临时表空间 ibtmp1 保留，1个为系统表空间使用，剩余的95个为 undo tablespaces 使用。 当 innodb_rollback_segments\u0026lt;=32的时候，系统将自动分配1个rollback …"

"从调度上看，goroutine的调度开销远远小于线程调度开销。\nOS的线程由OS内核调度，每隔几毫秒，一个硬件时钟中断发到CPU，CPU调用一个调度器内核函数。这个函数暂停当前正在运行的线程，把他的寄存器信息保存到内存中(暂时保存线程状态），查看线程列表并决定接下来运行哪一个线程，再从内存中恢复线程的注册表信息，最后继续执行选中的线程。这种线程切换需要一个完整的上下文切换：即保存一个线程的状态到内存，再恢复另外一个线程的状态，最后更新调度器的数据结构。某种意义上，这种操作还是很慢的。OS 线程调度器\nGo运行的时候包涵一个自己的调度器，这个调度器使用一个称为一个M:N调度技术，m个goroutine到n个os线程（可以用GOMAXPROCS来控制n的数量），Go的调度器不是由硬件时钟来定期触发的，而是由特定的go语言结构来触发的，他不需要切换到内核语境，所以调度一个goroutine比调度一个线程的成本低很多。\n从栈空间上，goroutine的栈空间更加动态灵活。\n每个OS的线程都有一个固定大小的栈内存，通常是2MB，栈内存用于保存在其他函数调用期间哪些正在执行或者临时暂停的函数的局部 …"

" https://cloud.tencent.com/developer/article/1006514 https://yq.aliyun.com/articles/27667 "

"今天利用docker容器创建mysql8.0的时候(window系统），指定了本地宿主机器的一个目录为容器mysql的datadir目录，发现创建失败了。\n创建命令：\n$ docker run -d --name mysql81 -v /e/container/mysql/mysql81/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -p 33081:3306 mysql 错误提示：\n$ docker logs mysql81 2019-01-26T03:05:42.567230Z 0 [Warning] [MY-011070] [Server] \u0026#39;Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it\u0026#39; is deprecated and will be removed in a future release. …"

"今天来公司自己构建了一个Dockerfile,放在一个经常用到的项目目录里，内容如下：\n# This is a comment FROM ubuntu:14.04 MAINTAINER Docker Newbee \u0026lt;[email protected]\u0026gt; RUN apt-get -qq update RUN apt-get -qqy install ruby ruby-dev RUN gem install sinatra 然后执行\nsudo docker build -t \u0026#34;cfanbo/test:v2\u0026#34; . 发现在构建的时候发送给 docker daemon 竟然有4G多，超极大。首先的第一反映出问题了。一个ubuntu镜像也没有这么大呀，况且现在还没有开始从远程pull 镜像呢。\n那到底什么情况了呢？经过一翻搜索，发现在docker build . 的时候，会将当前目录里的内容发送给 docker daemon。只需要加一个 .dockerignore 文件，将其它内容排除掉就可以了，类似于git中的.gitignore文件的作用。\n后面就想通 …"

"每个aliyun账号都有一个专属的镜像源\n我这里安装的是 Docker Toolbox 软件，更新docker源有两种情况，一种是你还没有创建过Docker Machine，另一种是你已经创建过了Docker Machine。\n一、未安装过 创建一台安装有Docker环境的Linux虚拟机，指定机器名称为default，同时配置Docker加速器地址。 $ docker-machine create –engine-registry-mirror=https://xxxx.mirror.aliyuncs.com -d virtualbox default\n查看机器的环境配置，并配置到本地。然后通过Docker客户端访问Docker服务。 $ docker-machine env default $ eval “$(docker-machine env default)” $ docker info\n这里 xxxx 是您的专有加速器地址\n二、已安装过\n登录已创建的Docker VM $ docker-machine ssh default $ sudo vi …"

"**函数语法： **\n**group_concat( [DISTINCT] 要连接的字段 [Order BY ****排序字段 **ASC/DESC] [Separator ‘分隔符’] )\n下面举例说明：\nselect * from goods;\n+——+——+ | id| price| +——+——+ |1 | 10| |1 | 20| |1 | 20| |2 | 20| |3 | 200 | |3 | 500 | +——+——+ 6 rows in set (0.00 sec)\n以id分组，把price字段的值在同一行打印出来，逗号分隔(默认) select id, group_concat(price) from goods group by id;\n+——+——————–+ | id| group_concat(price) | +——+——————–+ |1 | 10,20,20| |2 | 20 | |3 | 200,500| +——+——————–+ 3 rows in set (0."

"在开发过程时，我们经常会遇到 order by 排序操作，那么你知道什么时候MySQL才会进行排序操作，什么时候不需要时间排序操作？，下面我们就从一个很小的例子中了解一下排序场景。\n表结构如下：\nCREATE TABLE t ( id int(11) unsigned NOT NULL AUTO_INCREMENT, city varchar(16) NOT NULL, name varchar(16) NOT NULL, age int(11) NOT NULL, addr varchar(128) DEFAULT NULL, PRIMARY KEY (id), KEY city (city) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 这里只有一个索引city，我们执行一条SQL语句：\nSELECT city, name FROM t WHERE city=\u0026#39;杭州\u0026#39; ORDER BY name LIMIT 1000; 通过Explain命令查看执行情况\n发现Extra字段里有”Using …"