1、不要在查询中使用 !=、not in、not exists
2、不要在where条件的等号左侧中使用函数
3、MySQL支持前缀索引，但是不支持后缀索引LIKE '%A’优化为： LIKE ‘A%’
4、设置联合索引时，索引的建立顺序要和where或者order by条件中的字段顺序相同，如建立name、status（分别为key1、key2）的联合索引，此时以name字段为第一查询顺序的索引有效
5、where条件中有or，需将or中的每个字段都加上索引
6、状态值少的字段不宜使用索引
7、数据类型不匹配
limit优化：where id>= (select id from mytbl order by id limit 100000,1)limit 10
b+
1，非叶子节点只存储键值信息（key信息）
2，所有叶子节点之间都有一个链指针，数据都存放再叶子节点中
每个MyISAM在磁盘上存储成三个文件。
（1）frm文件：存储表的定义数据
（2）MYD文件：存放表具体记录的数据
（3）MYI文件：存储索引
frm和MYI可以存放在不同的目录下。MYI文件用来存储索引，但仅保存记录所在页的指针，索引的结构是B+树结构。下面这张图就是MYI文件保存的机制：
支持数据的类型也有三种：
（1）静态固定长度表
这种方式的优点在于存储速度非常快，容易发生缓存，而且表发生损坏后也容易修复。缺点是占空间。这也是默认的存储格式。
（2）动态可变长表
优点是节省空间，但是一旦出错恢复起来比较麻烦。
（3）压缩表
上面说到支持数据压缩，说明肯定也支持这个格式。在数据文件发生错误时候，可以使用check table工具来检查，而且还可以使用repair table工具来恢复。
有一个重要的特点那就是不支持事务，但是这也意味着他的存储速度更快，如果你的读写操作允许有错误数据的话，只是追求速度，可以选择这个存储引擎。
InnoDB是默认的数据库存储引擎，聚簇索引，支持外键，innodb page默认16kb，他的主要特点有：
（1）可以通过自动增长列，方法是auto_increment。
（2）支持事务。默认的事务隔离级别为可重复度，通过MVCC（并发版本控制）来实现的。
（3）使用的锁粒度为行级锁，可以支持更高的并发；
（4）支持外键约束；外键约束其实降低了表的查询速度，但是增加了表之间的耦合度。
（5）配合一些热备工具可以支持在线热备份；
（6）在InnoDB中存在着缓冲管理，通过缓冲池，将索引和数据全部缓存起来，加快查询的速度；
（7）对于InnoDB类型的表，其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。数据和索引放在一块，都位于B+数的叶子节点上；
对于InnoDB来说，最大的特点在于支持事务。但是这是以损失效率来换取的。
二级索引：叶子节点中存储主键值，每次查找数据时，根据索引找到叶子节点中的主键值，根据主键值再到聚簇索引中得到完整的一行记录。
InnoDB在移动行时，无需维护二级索引，因为叶子节点中存储的是主键值，而不是指针。而唯一索引、普通索引、前缀索引等都是二级索引。
InnoDB中表中的数据是直接存储在主键聚簇索引的叶子节点中的，每插入一条记录，其实都是增加一个叶子节点，如果主键是顺序的，只需要把新增的一条记录存储在上一条记录的后面，当页达到最大填充因子的时候，下一跳记录就会写入新的页中，这种情况下，主键页就会近似于被顺序的记录填满。若表的主键不是顺序的id，而是无规律数据，比如字符串，InnoDB无法加单的把一行记录插入到索引的最后，而是需要找一个合适的位置（已有数据的中间位置），甚至产生大量的页分裂并且移动大量数据，在寻找合适位置进行插入时，目标页可能不在内存中，这就导致了大量的随机IO操作，影响插入效率。除此之外，大量的页分裂会导致大量的内存碎片。
Mongodb是非关系型数据库(nosql ),属于文档型数据库。文档是mongoDB中数据的基本单元，类似关系数据库的行，它是一个面向集合的，模式自由的文档型数据库。
存储方式：虚拟内存+持久化。
查询语句：是独特的Mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
优点：
快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。高扩展性，存储的数据格式是json格式！
缺点：
不支持事务，而且开发文档不是很完全，完善。
一个database中所有的collections以及索引信息会分散存储在多个数据文件中，即mongodb并没有像SQL数据库那样，每个表的数据、索引分别存储；数据分块的单位为extent（范围，区域），即一个data file中有多个extents组成，extent中可以保存collection数据或者indexes数据，一个extent只能保存同一个collection数据，不同的collections数据分布在不同的extents中，indexes数据也保存在各自的extents中；最终，一个collection有一个或者多个extents构成，最小size为8K，最大可以为2G，依次增大；它们分散在多个data files中。对于一个data file而言，可能包含多个collection的数据，即有多个不同collections的extents、index extents混合构成。每个extent包含多条documents（或者index entries），每个extent的大小可能不相等，但一个extent不会跨越2个data files。
每个collection只保存了第一个extent的位置信息，并不保存所有的extents列表，但每个extent都维护者一个链表关系，即每个extent都在其header信息中记录了此extent的上一个、下一个extent的位置信息，这样当对此collection进行scan操作时（比如全表扫描），可以提供很大的便利性。
对于write操作而言，首先写入journal日志，然后将数据在内存中修改（mmap），此后后台线程间歇性的将内存中变更的数据flush到底层的data files中，时间间隔为60秒（参见配置项“syncPeriodSecs”）；write操作在journal文件中是有序的，为了提升性能，write将会首先写入journal日志的内存buffer中，当buffer数据达到100M或者每隔100毫秒，buffer中的数据将会flush到磁盘中的journal文件中；如果mongodb异常退出，将可能导致最多100M数据或者最近100ms内的数据丢失，flush磁盘的时间间隔有配置项“commitIntervalMs”决定，默认为100毫秒。
1）ODS层（原始数据层）
原始数据层，存放原始的数据，直接加载原始日志、数据，数据保持原貌不作处理。
2）DWD层（明细数据层）
结构和粒度与原始数据表保持一致，对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）
3）DWD层（服务数据层）
以DWD为基础，进行轻度汇总。一般聚集到以用户当日，设备当日，商家当日，商品当日等等的粒度
4）ADS层（数据应用层）
ADS层，为各种统计表提供数据，也有的地方把这层叫做APP层、DM层等等。
Hadoop是一个分布式系统基础架构。解决了大数据（大到一台计算机无法进行存储，一台计算机无法在要求的时间内进行处理）的可靠存储(HDFS)和处理(MapReduce)。
Hive是建立在Hadoop之上的，使用Hadoop作为底层存储的批处理系统。（可以理解为MapReduce的一层壳）Hive是为了减少MapReduce jobs的编写工作。
HBase是一种Key/Value系统，它运行在HDFS之上。Hbase是为了解决Hadoop的实时性需求。
Spark和Storm都是通用的并行计算框架。解决Hadoop只适用于离线数据处理，而不能提供实时数据处理能力的问题。
HIve清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase
数据应用从HBase查询数据；
线程进程通信
管道（pipe）：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有血缘关系的进程间使用。进程的血缘关系通常指父子进程关系
命名管道（named pipe）：命名管道也是半双工的通信方式，但是它允许无亲缘关系进程间通信
信号量（semophore）：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它通常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段
消息队列（message queue）：消息队列是由消息组成的链表，存放在内核中 并由消息队列标识符标识。消息队列克服了信号传递信息少，管道只能承载无格式字节流以及缓冲区大小受限等缺点
信号（signal）：信号是一种比较复杂的通信方式，用于通知接收进程某一事件已经发生
共享内存（shared memory）：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问，共享内存是最快的IPC方式，它是针对其他进程间的通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号量配合使用，来实现进程间的同步和通信
套接字（socket）：套接口也是一种进程间的通信机制，与其他通信机制不同的是它可以用于不同及其间的进程通信
进程=火车，线程=车厢
线程在进程下行进（单纯的车厢无法运行）
一个进程可以包含多个线程（一辆火车可以有多个车厢）
不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）
进程可以拓展到多机，进程最多适合多核（不同火车可以开在多个轨道上，同一火车的车厢不能在行进的不同的轨道上）
进程使用的内存地址可以上锁，即一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。（比如火车上的洗手间）
－"互斥锁"进程使用的内存地址可以限定使用量（比如火车上的餐厅，最多只允许多少人进入，如果满了需要在门口等，等有人出来了才能进去）－“信号量”
volatile底层：汇编代码中volatile关键字的代码会多出一个lock前缀指令。
lock前缀指令实际相当于一个内存屏障，内存屏障提供了以下功能：
1 . 重排序时不能把后面的指令重排序到内存屏障之前的位置
2 . 使得本CPU的Cache写入内存
3 . 写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于让新写入的值对别的线程可见。
应用：状态量标记和单例模式的实现
正则表达式：Pattern 类；java中\代表一个\
1.用UUID生成十六位数唯一订单号
2.也可以时间+随机数
3.高并发性下，确保订单的唯一性，可以把用户id加进去
4.雪花算法
UUID有一些缺点，首先他相对比较长，另外UUID一般是无序的。
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。
本文地址：https://blog.csdn.net/haxiao2015/article/details/107293767
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论