随着互联网的兴起，pc产业就进入后pc时代。

通常认为，后pc时代，手机和平板逐渐崛起，台式机和笔记本逐渐没落。

但是对于经济不济的现实环境，大部分行业都无法完全丢弃pc转向手机平板并且减少开支和提高办公效率，传统的台式机因为费用低，办公效率高，在未来的几十年里仍然占据主流地位。

对于大部分上班族，没有台式机和笔记本就谈不上工作效率，上班使用手机和平板目前以及未来很长一段时间都是不可能的。

先把时间和精力，解决好业务代码。

在有能力的情况下，多学习新技术，不同的技术，学习难度较小，另外或许就能带来不同的思路，更好的解决业务问题。

光从现有知识，往往不能较大的提升现有系统。除了精心设计外，比较简单有效的提升，就是学习更多的新技术，因为学习是比较简单的，而在知识不增长的情况下要对系统重构或提升则会非常困难。

比如你做python、php或其他，甚至都可以考虑跨语言，虽然代码不同，但是解决问题的思路是可以通用的。

每天至少写几篇博客，看几篇技术文章、看一些技术视频、甚至学一新词汇，都会带来不同的思路。

一般可能会使用 ctrl + d，或手动点击保存。

但是通常都不好，因为每次都要选择位置。（比如选中某个文件夹、或直接选择在收藏栏中）

而选择某个目录、或收藏栏后，由于书签比较多，会排在最后，效果非常不好。

解决办法：拖动地址栏URL。

点一下地址栏，会自动把地址栏进入编辑状态，此时按住拖动，即可放到指定位置，这样最方便。

其他提示：按住已有书签，往下拖动，就可以在新页面打开该书签。

限制其body高度

指定 .modal-body 高度，超过后以滚动条形式展示

        .modal-body{

            max-height:400px;

            overflow-y:auto;

        }

不支持 count(*)

所以必须 count 一个字段，推荐使用 id

例如：

select count(id) from table_name;

“||”：字符拼接

select 'a' || 'b' //结果是ab

查询字段，实例：

SELECT (`parent_path`||`server_filename`)'path','12312344' as 'uk' FROM "cache_file" limit 0, 100

除了心态方面，充分的准备，也可以让我们变得自信。

以前，如果在我不熟悉的城市做讲座，我会很紧张。一边穿梭于车流中，一边看着地图寻找陌生的地址，这对我的神经来说，真是极大的考验。后来，我学会了一个更好的办法。

我会在研讨会的前一天到达，然后在晚上驾车去所在地转一转，探探情况，以免第二天遭遇交通阻塞。我会选择最佳路线，找到合适的停车地点。如果是在一家宾馆，我就会进去，找到第二天将要使用的会议室。整个过程也用不了太久，但是，第二天的感觉就会完全不同。充分准备会减轻我的压力感。

可以说，充分准备是让交谈更为顺利的最简单的方式，预先思考的越多，你就越自信。

不管你处在何种水平，都有进步的空间。坚持下去，时间长了，你就会养成事先充分思考和准备的习惯。

使用 concat 连接两个表

SELECT * FROM tb1 JOIN tb2 ON tb1.a=tb2.a
WHERE tb1.b LIKE CONCAT('%',tb2.b,'%')

update 表 join 表2

这里的 join 可以是普通的 join ，也可以是 left join， full join 等

UPDATE employees
        LEFT JOIN
    merits ON employees.performance = merits.performance 
SET 
    salary = salary + salary * 0.015
WHERE
    merits.percentage IS NULL;

一般而言主从就是读写分离，写请求指派到主机，读请求指派到从机。

还有相似概念，主备，备机是不干活的，也就是不对外提供服务，只是默默地在同步主机的数据，然后等着某一天主机挂了之后，它取而代之！

主主就是两个都是主机。一般情况下都不会有主主的架构。

为什么读写分离？

读写分离就是读操作和写操作从以前的一台服务器上剥离开来，将主库压力分担一些到从库。

本质上是因为访问量太大，主库的压力过大，单机数据库无法支撑并发读写。

然后一般而言读的次数远高于写，因此将读操作分发到从库上，这就是常见的读写分离。

读写分离还有个操作就是主库不建查询的索引，从库建查询的索引。

因为索引是需要维护的，比如你插入一条数据，不仅要在聚簇索引上面插入，对应的二级索引也得插入，修改也是一样的。

所以将读操作分到从库了之后，可以在主库把查询要用的索引删了，减少写操作对主库的影响。

读写分离的两种方式：代码实现、中间件

代码实现：

讲白了就是代码层面抽出一个中间层，由中间层来实现读写分离和数据库连接。

就是搞了个代理类，对外暴露正常的读写接口，里面封装了逻辑，将读操作指向从库的数据源，写操作指向主库的数据源。

• 优点：简单，并且可以根据业务定制化变化，随心所欲。
• 缺点：如果数据库宕机了，发生主从切换了之后，就得修改配置重启。如果系统是多语言的话，需要为每个语言都实现一个中间层代码，重复开发。

中间件：

一般而言是独立部署的系统，客户端与这个中间件的交互是通过 SQL 协议的。

所以在客户端看来连接的就是一个数据库，通过 SQL 协议交互也可以屏蔽多语言的差异。

缺点就是整体架构多了一个系统需要维护，并且可能成为性能瓶颈，毕竟交互都需要经过它中转。

常见的开源数据库中间件有：官方的MySQL-Proxy、360的Atlas、Mycat 等。

MySQL 主从同步机制

主从同步主要依赖的就是 binlog，MySQL 默认是异步复制，具体流程如下：

主库：

• 接受到提交事务请求
• 更新数据
• 将数据写到binlog中
• 给客户端响应
• 推送binlog到从库中

从库：

• 由 I/O 线程将同步过来的 binlog 写入到 relay log 中。
• 由 SQL 线程从 relay log 重放事件，更新数据
• 给主库返回响应。

用一句话概括一下：主库提交事务会写binlog，会由一个 dump 线程推送给从库，从库接受之后会有一个I/O线程将其写到 relay log 中，慢慢消化，由 SQL 线程来重放更新数据。

异步复制有数据丢失风险，例如数据还未同步到从库，主库就给客户端响应，然后主库挂了，此时从库晋升为主库的话数据是缺失的。

所以有同步复制，主库需要将 binlog 复制到所有从库，等所有从库响应了之后才会给客户端响应，这样的话性能很差，一般不会选择同步复制。

MySQL 5.7 之后搞了个半同步复制，有个参数可以选择“成功同步几个从库就返回响应。”

比如一共有 3 个从库，我参数配置 1，那么只要有一个从库响应说复制成功了，主库就直接返回响应给客户端，不会等待其他两个从库。

这样的话性能就比较好，并且数据可靠性也增强了，只有当那个从库和主库同时都挂了，才会缺失数据。

主从同步延迟处理

从流程就可以得知，延迟是必然存在的。

延迟过大的话就有可能出现一个用户刚注册，然后登陆报该用户不存在的….

因为数据是写到主库中的，查询走从库有可能还未来同步完毕，导致查不到这个用户。

这就非常不友好了。

常见解决方式有以下几种：

• 二次查询。如果从库查不到数据，则再去主库查一遍，由 API 封装即可，算是一个兜底策略，比较简单。不过等于读的压力又转移到主库身上了，如果有不法分子估计搞一下必定查不到的查询，这就难受了。
• 强制将写之后立马读的操作转移到主库上。这种属于代码写死了，比如一些写入之后立马查询的操作，就绑定在一起，写死都走主库。不推荐，太僵硬了。
• 关键业务读写都走主库，非关键还是读写分离。比如上面我举例的用户注册这种，可以读写主库，这样就不会有登陆报该用户不存在的问题，这种访问量频次应该也不会很多，所以看业务适当调整此类接口。