你的服务器内存2G,你全表查询一个10g的表，内存会不会炸了。
不会。逻辑如下，语句，select * from t；服务端不会存放完整的结果集，其流程和流很类似。
１.获取一行，写到net_buffer中。这个值由参数net_buffer_length决定，默认16k。
２.重复获取行，直到，写满net_buffer
３.若发送成功，就清空net_buffer,然后取下一行，写入搭配net_buffer。
４.如果发送函数返回EAGAIN,或者WSAEWOULDBLOCK。就表示本地网络栈满了，进入等待，直到可以重写，再继续发送。
-quick：mysql_use_result方法，这个方法是读一行，处理一行。默认的话mysql_store_result这个接口。这个是把结果保存到本地内存。
mvn deploy:deploy-file -DgroupId=net.sf.squirrel-sql.plugins -DartifactId=greenplum -Dversion=3.5.0 -Dpackaging=jar -Dfile=C:\Users\Lenovo.m2\repository\net\sf\squirrel-sql\plugins\greenplum\3.5.0\greenplum-3.5.0.jar -Durl=http://maven.×××.com/nexus/content/repositories/thirdparty/ -DrepositoryId=3rd.nexus –settings D:\maven\apache-maven-3.5.0\conf\settings.xml
其中-DgroupId 为上传的jar的groupId
-DartifactId 为上传的jar的artifactId
-Dversion 为上传的jar的需要被依赖的时候的版本号
然后是-Dpackaging为jar，-Dfile为jar包路径
-Durl 为要上传的路径，可以通过以下方式获取到
-DrepositoryId 为repository的唯一标示，和setting.xml里面server相同
–settings 指定配置文件
一个主库，可以读写，一个从库可读，不可写。
流程：一个更新操作：
１．主库执行更新操作，写入到binlog里面。，备库和主库维持一个长连接。主库内部有个线程，专门用于服务备库的这个长连接。
2.备库通过change master 设置主库A的ip，端口，用户名，密码，以及要从哪个位置来请求binlog，这个位置包含文件名和日志偏移量。
３．备库执行start slave 命令，这个时候，备库会启动2个线程。一个叫做 io_thread（用来负责和主库建立连接），主库检验完用户名。密码后开始按照备库传过来的位置读取binlog，发送给备库，备库拿到数据后，放到relay log。另一个线程就是sql_thread ，读取relay log.然后执行。
双主结构：从节点和主节点互为主备关系。切换时不修改主备关系。但是从节点依旧是readonly.互为主备存在循环日志关系，比如a把binlog发给了b，b接受到后吧日志发给了a，如此就循环了，这边方法时每个库的serverid保持不一样，当接受日志的时候，当发现serverid和自己一样时，丢掉日志。
statement：记录原语句。
row：记录的是修改后的动作。比如删除 id=1,新增 id2=2等信息。直接记录的就是数据.
mix：混合上面2个格式的。为何有这种格式呢？statement，直接执行语句可能导致报错，而row占的空间太大。使用mix，不存在歧义的语句采用statement,存在歧义的使用row。
歧义sql:
delete from t where a>=4 and t_modified<=’2018-11-10’ limit 1;
其可能使用ａ这个索引，或者t_modified这个索引。采用不同索引，可能删除的数据不一样。
row格式日志其保存了修改前后的变化，如果误操作了，可以查看回滚。所以一般都是用这个row这种格式来记录binlog。如果用statement格式的binlog恢复数据时，要先用mysqlbinlog解析出来，再把结果发给mysql执行。
每个事务都有一个时间，这个时间就是主库写入时间，而主备延迟是从库写入的系统时间，减去这个主库写入时间的差值。这个时间值一般来源于，从库接受到数据，到写入到从库的时间。网络影响较小。
原因如下：
１.由于备库没有请求，于是给备库配置的机器极差，但是，备库同步数据时，对磁盘的操作也是有的，更新操作也很多，因此，造成了大量的延迟。
２．让备库去处理请求，由于考虑到只是读请求，因此不加限制，导致备库同步数据慢。
针对原因２解决方案：
１：增加几个从库
２．将信息binlog输出到外部系统Hadoop来减轻压力。
３．大事务，一个大的事务，在主库都执行了很久，何况从库。
４．DDL,ddl会重建表。而大表的重建，性能损耗很大。
３．备库的并行复制能力
１．判断延迟时间是否小于一个阈值。否则重复这一步。
２．将主库改为只读，
３．判断备库的延迟时间是否为０.
４．将备库改为可读写。
５，将请求切换到备库Ｂ．
其中最耗时的是步骤３，因此我们要控制好步骤一的阈值，从而减少不可用时间。 按照这个步骤可以让可靠性达到最高。，但是可用性会随之下降。假设先执行４．５步骤，可用性最高，一直可用，主库插入一个数据４，主键自增，（１,４）。然后切换主备，这个（１,４）没有写入到从库，然后新增数据５，从库存了（１,５）然后，接受到存４，存了（２,４）然后主从数据库不一致了。 如果是row格式的binlog，那就不是数据不一致，那是数据根本存不进去。
如果发生异常，主库宕机了，而从库延迟时间极长，那么切换为从库，会造成系统长时间不可用。因此mysql高可用是建立在延迟时间短的情况下的。
maven约定大于配置：
${basedir} 存放pom.xml和所有的子目录
${basedir}/src/main/java 项目的java源代码
${basedir}/src/main/resources 项目的资源，比如property文件，springmvc.xml
${basedir}/src/test/java 项目的测试类，比如说Junit代码
${basedir}/src/test/resources 测试用的资源
${basedir}/src/main/webapp/WEB-INF web应用文件目录，web项目的信息，比如存放web.xml、本地图片、jsp视图页面
${basedir}/target 打包输出目录
${basedir}/target/classes 编译输出目录
${basedir}/target/test-classes 测试编译输出目录
Test.java Maven只会自动运行符合该命名规则的测试类
~/.m2/repository Maven默认的本地仓库目录位置。
groupId：公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如
artifactId：项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的。
version：版本号。
project：工程的根标签。
modelVersion：模型版本，基本都是4.0
所有的pom都要继承一个父pom。父pom声明了一些可被继承的默认设置。maven使用effective pom(父pom+自己工程pom的配置)来执行目标，目的是为了尽可能减少配置。
validate：验证项目是否正确且所有必须信息是可用的。
compile：执行编译 源代码编译在此阶段完成。
Test：使用适当的单元测试框架（例如JUnit）运行测试
package：打包创建JAR/WAR包如在 pom.xml 中定义提及的包
verify： 检查 对集成测试的结果进行检查，以保证质量达标
install：安装安装打包的项目到本地仓库，以供其他项目使用
deploy： 部署 拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程
Maven根据坐标寻找构件的时候，它先会查看本地仓库，如果本地仓库存在构件，则直接使用；如果没有，则从远程仓库查找，找到后，下载到本地。
分类
本地仓库
远程仓库：
中央仓库：默认的远程仓库。maven的setting文件有个父pom,在你安装的maven的lib下的 maven-model-builde-xxx.jar解压，然后不断点击进入，找到super pom里面配置了一个id为central的中央仓库。
私服：私服是一种特殊的远程Maven仓库，它是架设在局域网内的仓库服务，私服一般被配置为互联网远程仓库的镜像，供局域网内的Maven用户使用。当Maven需要下载构件的时候，先向私服请求，如果私服上不存在该构件，则从外部的远程仓库下载，同时缓存在私服之上，然后为Maven下载请求提供下载服务，另外，对于自定义或第三方的jar可以从本地上传到私服，供局域网内其他maven用户使用。
profile。
普通远程仓库。
每个用户只能有一个本地仓库，和多个远程仓库。
maven镜像：
当远程仓库被镜像匹配到，那么获取jar将从镜像仓库获取，而不是我们配置的repository仓库。
ps：这个镜像，个人觉得，类似于拦截器，用于拦截父pom，以及你项目配置的仓库。拦截后使用，setting文件里面的pom文件。没有匹配到远程仓库的毫无意义。匹配到的则是替换。因此远程仓库和镜像是一个级别。
获取jar的优先级。
本地仓库 > 私服 （profile）> 远程仓库（repository）和 镜像 （mirror） > 中央仓库 （central）
我们有２个方式和服务端集群交互，第一个是通过9300端口并使用Elasticsearch原生传输协议和集群交互，同时集群的节点也是通过这个端口彼此通信的。这个只能通过java实现，同时maven依赖版本必须和es版本保持一致，不然可能连不上去。第二个方式就是其他语言包括java都可以使用的，就是通过restful api 9200端口和Elasticsearch交互。
１．ES的搜索引擎严重依赖于底层的filesystem cache，你如果给filesystem cache更多的内存，尽量让内存可以容纳所有的idx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。一般来说，内存空间要达到磁盘数据量的一般，使用es性能才好。
２.在es中，如果内存留给filesystem cache的空间是1g，那么你的索引数据就要控制在1g以内，那么你的数据几乎都是走内存来搜索，性能极高。比如你只需要根据id，name,age3个字段来搜索，但是你把一行数据30多个字段都丢进去了，那么有大量的数据不是用来搜索的，占了filesystem cache的空间，浪费了。因此我们建议将id+name,age,其余的数据存在mysql里面，然后通过索引再mysql里面查询。
３．数据预热，可以搞个子系统，手动访问某些数据，将数据加热，提前刷到filesystem cache里面。
４．es深度分页性能很差，方案，去除深度分页。
Elasticsearch是通过Lucene的倒排索引技术实现比关系型数据库更快的过滤。特别是它对多条件的过滤支持非常好，倒排索引。
1.解耦合，使得代码更加容易扩展升级。标准版的升级只要不是接口的变化，对其他服务影响为0.
2.领导提出的按图搜房，大量数据的汇总展示。我们维护一个数据源，易于分析，展示。
3.开放出人力成本，一个人可以维护一个或者多个微服务，极大的节约了人力成本。
1.对开发要求高，以及重构成本。
1.整体思路。一个基础中心微服务+多个城市特色微服务。
2.基于标准版拆分出多个微服务。每个微服务提供粒子化的对外微服务。
1.首先，登录模块必须独立出来。作为一个独立的微服务，登录模块拆分出来。
思路如下：通过不同url访问前端，前端请求该微服务，服务返回token即可。带着该token访问其他微服务即可。
2.基本工具，基本字典的数据微服务
3.关于不同端的合同发布，备案，本质上是一个service实现的，可能存在部分字段差，这些可以放在一个微服务里面（同理这些具体业务也可以继续拆分为不同的微服务）更加粒子化。可以让备案，房源，做成对外提供服务的基础组件。
4.定时器，这个单独的工程可以直接拆到各个微服务里面，比如很多宽表的同步，个人觉得意义不是很大，可以优化。
3.多个城市特色微服务。一个地方城市就建立一个微服务，其开发工作就是调用基础中心对外的服务的拼装，需要什么就拿什么，就和堆积木一样。如此构成了一个遍布全国的微服务网络。这样服务就可以连起来了。数据也统一起来了。
方案1:中心数据库冗余存储一个字段json类型，可以冗余存储多个字段。
方案2：中心保存最重要的数据，特色城市在维护一个冗余表保存特色字段（存在分布式事务问题）
方案1：基础中心产品评判这个功能是否普遍性较高，若是很高，加入到基础中心微服务里面，反之，特色微服务自己实现一遍，同时把数据也拼装到基础中心（差异太大，没办法，就是相当于重做了，没有的办法）。
方案1：基础中心设计一个基于配置化的功能，开发在上面点击选择后，可以迅速生成一个简单的脚手架，加速开发，而不是纯粹的复制，减少了大量开发工作。
如若有新的功能，可以由保准化产品定论是否标准化，标准化后再提供微服务调用。
后续新增。每周更新
1.前端同学开发应该是基于antd组件的，可以建议开发一个界面设计器。界面设计器的目的是减少前端的开发量，将html和js分离，界面设计器的概念是我们在界面上配置界面展示如何。然后我们根据配置界面后得到的唯一标识符，只负责编写业务逻辑js代码，可以有效提高前端在新业务上开发的效率。
我们可以使用混合云的思路和模式，很多对外城市开发的产品，大多数城市对安全要求很严谨。因此我们不可能将其作为一个微服务放到大的微服务集群里面，因为这是在公有云体系里面，这样安全存在问题，我们必须使用私有云服务体系，将当前这个城市需要的微服务，我们将其提取出来，放到一个私有云里面。然后将其组装为该城市需要的系统，如此既保证了安全的特性，又保证了服务的可用性。
定制化存在这么一个问题，你提供的标准版是稳定的吗？第一可能存在bug,安全漏斗等问题，第二可能存在二次迭代更新，业务定制方也有特色开发，如此造成2个分流的分支，将来如何能合在一起呢？这也是我们公司目前的方案，所以我写了2篇文章来思考新的方案。
公司预定义一个标准化的saas服务。预先面向A公司（行业龙头，因此具有 一定规范度）提供标准化开发（产品与A公司专门业务人员沟通，提取出公 共化方案）。成功上线后，推广到其他公司b,c,d。发现其他公司的内部流程 算法，界面不适应于标准化版本。
建立组织层级，建立一个微服务档案列表，不同集团对应不同层级同时和登 录信息绑定。对于存在差异的算法（计算公式，是否采用不同方案）等，界 面显示（字段，按钮）等，单线流程（a公司是否需要流程123,但是b公司需 要流程1,3）等，在需要修改的点，以及这个组织id,在档案里面进行配置，不 同组织不同的方案，然后代码读取档案里面的信息，根据档案里面的这些信 息来完成差异统一。这样我们就可以用一个标准化版本了。上述档案归产品 经理管，负责维护（重要） 有些公司对于样式，布局等要求频繁变化，我们可以推出一部分档案权 限给客户，让其自行进行配置选择展示效果。
在开发中，我们发现一个线的流程太长了，比如开发Ａ功能，在Ａ功能界面 上需要但需要获取调用其他功能比如Ｂ的数据信息展示而这些数据信息却放 在其他微服务里面，我们也许会直接发送ajax请求其他微服务的信息，但是 存在几个问题（1.即时我们共用一个登陆系统，可以直接把登陆信息放到请 求头里面，可以直接访问到数据，但是这样不规范，A微服务前端访问到了B 微服务的后端，即使在一个微服务里面，我们直接访问其他功能的数据，这 样也不规范，也不好维护，万一这个接口修改了，修改的人也不知道到底多 少人调用了这个接口，怎么调用的等很多问题）
参照这个功能解决上述问题。每个功能可以对外提供一个或者多个的数据接 口。 该功能结构主要包含下述几点： １．一个包含增删改查的一个存储数据的界面。主要存放：该功能对外 提供的rest接口，需要展示的数据类型，界面展示风格（树表，列表，树， 主要这几个结构）。 ２．一个前端组件：通过开发配置的信息，展示数据。并且前端也可以 获取数据等。 这样界面调用展示数据，更加利于维护。
１．处理掉占着的但是不工作的连接。首先使用show processlist，但是不知道那些sleep的连接是否是事务外的，我们继续查询 information_schema库的innodb_trx表。select * from information_schema.innodb_trx\G,查看那些连接是在事务内的。
当我们断掉连接后，客户端不会立马知道，而是在第二个请求时才发现，连接断了。
２．减少连接过程的消耗，比如去掉安全校验。
３．索引没设计好，当要修改表结构时。可以采用如下方案。１，从库执行 set sql_log_bin=off,也就是不开启binlog,然后执行alter语句，主备切换，主库和上述从库一样的方案。
B+树的快速定位能力，来源于同一层兄弟节点的有序性。当你使用函数时，在b+树的第一层就不知道如何是好了。对索引字段做函数操作，会破坏其有序性。
既然这样，对mysql来说，字符串和数字比较是将字符串转换为数字，因此你一个字符串索引，当你的查询条件是数字时，会自动加上函数，导致其，破坏其有序性，导致进行全索引扫描。
１.临时表和内存表不一样的，临时表不全是内存表。但是临时表可以是内存表。
特点：
１．临时表可以和普通表同名。
２．创表语法为create temporaty table.
３．临时表只能被创建他的session访问，对其他线程不可见。
４．在一个session里面遇到同名的临时表和普通表时，优先访问临时表。
原因：mysql创建一个frm文件保存表结构，这个文件的后缀是.frm，前缀是#sql{进程id}{线程id}序列号。因此对于mysql来说，其真实存储的文件名是不一样的。
在mysql内存里面，每个表对应一个key,这个key是唯一的，普通表和数据库+表名相关，临时表则多了一个线程id。因此对于mysql来说，每个session创建的临时表的内存key和物理表名都不一样。
在实现上，每个线程维护了一个临时表链表，每次session内操作表的时候，先遍历链表，检查是否存在这个名字的临时表，有，则优先执行。session结束，则删除这个临时表。
主从：
如果binlog的格式是statment/mixed,是会把临binlog里面。时表记录到binlog里面，但是如果是row则不会记录到里面。
内存表的索引结构是hash结构，查询很快，但是加锁时表锁。在高可用也就是主从的情况下可能导致数据丢失，报错。
在mysql5.7以及之前的版本，主键自增的值，保存在内存里面，没有持久化，每次重启后，第一次打开表的时候，都会查找出来最大的id,加一作为新的当前自增值。
在mysql8.0之后，这时就会将自增至的记录在了redolog中。重启时依靠redolog来恢复值。
策略：
１:插入数据id为0，null,未指定值，那么mysql就会将这个表当前的AUTO_INCREMENT插入到自增字段里面。
２．如果插入数据时，指定了id的值，那就用语句里面指定的值。同时有以下策略，如果指定的值，小于自增值，那么自增值不变，如果大于等于自增值，那么就需要更新自增值，使其大于某个值。策略如下：从 auto_increment_offset 开始，以 auto_increment_increment 为步长持续叠加，直到找到第一个大于 X 的值，作为新的自增值。其中auto_increment_offset默认是1，表示增长的幅度.
唯一键冲突，事务回滚可能导致主键自增不连续。（双一）。还有就是批量插入时，也可能导致主键不连续，因为批量插入时，为了效率，分配1,2,4指数式增长。即使分配的没有用完，也不会回滚。
mysql这么设计为了性能考虑。获取主键时，肯定要加锁2个session,A得到2，B得到3，B成功，A失败。如此的话，表设计会比较麻烦。
在mysql 5.1.22有了一个参数innodb_autoinc_lock_mode，默认是1，有三个值
０：一条语句申请自增锁，整个语句执行完才释放锁。
１：单插入语句，申请完就释放，多插入语句，整个执行完释放锁（因为不然可能导致主从存在问题，binlog是statement时，场景如下，sessionA 批量插入10,数据，sessionB插入1数据，可能sessionA的10数据不连续，但是对于binlog来说是顺序的，可能出现问题）。
２．所有都是申请完就释放。
因此建议使用2+binlogrow
ps:在未指定，null,0时，采用主键自增。
主键自增，int最大值为2/32 -1,如果到了最大值，继续插入会报错，主键冲突，因为它不会继续增加了。如果有可能，建议创建bigint unsigned。更大一些。
在mysql innodb里面，如果没有创建主键，那么创建一个不可见，长度为6个字节的row_id,innodb维护了一个全局的dict_sys_row_id,所有无主键的innodb表，每插入一行数据，都要将dict_sys_row_id值作为要插入数据的row_id,然后将这个值+1。
这个row_id的大小是6字节，最大值为2/48-1，当达到最大值时，会重新从0开始。可能存在rowid重复，那么就会新的值覆盖旧的值。覆盖数据意味着数据丢失，因此最好每个表都创建一个主键。
redolog和binlog配合的时候有个字段叫做Xid，这个字段是用来对应一个个事务的，在mysql里面，维护了一个全局变量global_query_id,每次执行语句时，将它赋值给Query_id,然后给这个变量加1，如果当前语句时这个事务执行的第一条语句，那么mysql还会同时把query_id赋值给这个事务的Xid。这个全局变量是内存变量，重启后就清空，因此，同一个数据库里面，可能binlog里面存在相同的xid，但是重启之后，mysql会创建一个新的binlog文件，因此同一个binlog文件不会存在相同的xid
这个id大家都很熟了，和事务隔离相关，这个是innodb自己维护的，innodb维护了一个叫做max_try_id全局变量，每次申请值的时候，就会获取这个全局变量的当前值，然后将这个值+1；innodb只会在当前事务涉及到修改更新操作时才会分配trx_id。不给只读事务分配trx_id，直接默认为0，可以有效减少活跃事务表的大小，同时减少了trx_id的分配，变相提高了trx_id的吞吐量。max_try_id会持久化存储，重启也不会重置为0，因此存在运行时间足够久的事务中存在，后创建的事务id小于之前创建的事务id，造成脏读。当然这个值的最大值是2/48-1。一个mysqlqps50，持续18年就会出现这样的问题。
thread_id是线程id，系统保存了一个全局变量 thread_id_counter,每新建一个连接，就将thread_id_counter赋值给这个线程变量。最大值是2/32-1，但是达到最大值后，就会从0开始，但是在mysql里面不会存在2个相同的值，因为分配thread_id时，做了去重处理，判断这个id是否存在于当前活跃线程id里面。
Cookie不仅仅有名字和值两个属性，还有域（domain）、路径（path）等属性。其中，不同的域、不同的路径下可以存在同样名字的cookie。一般我们设置cookie的方法是用一个同样名字、一个值。这时就一定要搞清楚你要设置的cookie的域和路径，否则就会产生问题中的情况
１．name Cookie的名称，Cookie一旦创建，名称便不可更改
２．value Cookie的值。如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码
３．maxAge Cookie失效的时间，单位秒。如果为正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为-1。
４．secure 该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
５．path Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。
６．domain 可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。
domain表示的是cookie所在的域，默认为请求的地址，如网址为www.test.com/test/test.aspx，那么domain默认为www.test.com。而跨域访问，如域A为t1.test.com，域B为t2.test.com，那么在域A生产一个令域A和域B都能访问的cookie就要将该cookie的domain设置为.test.com；如果要在域A生产一个令域A不能访问而域B能访问的cookie就要将该cookie的domain设置为t2.test.com