| MyISAM | Innodb | |
|---|---|---|
| 存储结构 | 每张表被存放在三个文件：<br />frm表格定义、MYD(MYData)数据文件、<br />MYI(MYIndex)-索引文件 |
所有的表都保存在同一个数据文件中.ibd frm表格定义、（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB |
| 存储空间 | MyISAM可被压缩，存储空间较小 | InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引 |
| 可移植性、备份及恢复 | 由于MyISAM的数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作 | 免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了 |
| 文件格式 | 数据和索引是分别存储的，数据.MYD，索引.MYI |
数据和索引是集中存储的，.ibd |
| 记录存储顺序 | 按记录插入顺序保存 | 按主键大小有序插入 |
| 外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 锁支持（锁是避免资源争用的一个机制，MySQL锁对用户几乎是透明的） | 表级锁定 | 行级锁定、表级锁定，锁定力度小并发能力高 |
| SELECT | MyISAM更优 | |
| INSERT、UPDATE、DELETE | InnoDB更优 | |
| select count(*) | myisam更快，因为myisam内部维护了一个计数器，可以直接调取。 | |
| 索引的实现方式 | B+树索引，myisam 是堆表 | B+树索引，Innodb 是索引组织表 |
| 哈希索引 | 不支持 | 支持 |
| 全文索引 | 支持 | 不支持 |
hash索引底层就是hash表，进行查找时，调用一次hash函数就可以获取到相应的键值，之后进行回表查询获得实际数据。
B+树底层实现是多路平衡查找树。对于每一次的查询都是从根节点出发，查找到叶子节点方可以获得所查键值，然后根据查询判断是否需要回表查询数据。因为两者数据结构上的差异导致它们的使用场景也不同，哈希索引一般多用于精确的等值查找，B+索引则多用于除了精确的等值查找外的其他查找。在大多数情况下，会选择使用B+树索引。
select * from table_name where a = 1 and b = 2 and c = 3
select * from table_name where b = 2 and a = 1 and c = 3
上面两次查询过程中所有值都用到了索引，where后面字段调换不会影响查询结果，因为MySQL中的优化器会自动优化查询顺序。
select * from table_name where a = 1
select * from table_name where a = 1 and b = 2
select * from table_name where a = 1 and b = 2 and c = 3
答案是三个查询语句都用到了索引，因为三个语句都是从最左开始匹配的。
select * from table_name where b = 1
select * from table_name where b = 1 and c = 2
答案是这两个查询语句都没有用到索引，因为不是从最左边开始匹配的
select * from table_name where a = 1 and c = 2
这个查询语句只有a列用到了索引，c列没有用到索引，因为中间跳过了b列，不是从最左开始连续匹配的。
select * from table_name where a = 1 and b < 3 and c < 1
这个查询中只有a列和b列使用到了索引，而c列没有使用索引，因为根据最左匹配查询原则，遇到范围查询会停止。
select * from table_name where a like 'ab%';
select * from table_name where a like '%ab'
select * from table_name where a like '%ab%'
对于列为字符串的情况，只有前缀匹配可以使用索引，中缀匹配和后缀匹配只能进行全表扫描。
1NF：原子性。 字段不可再分,否则就不是关系数据库;； 2NF：唯一性 。一个表只说明一个事物； 3NF：每列都与主键有直接关系，不存在传递依赖。
select * from table_name where a = 1 or b = 3select * from table_name where a + 1 = 2select * from table_name where a = '1'会使用到索引，如果写成select * from table_name where a = 1则会导致索引失效。select * from table_name where abs(a) = 1select * from table_name where a != 1select * from table_name where a is null在不可重复读中，发现数据不一致主要是数据被更新了。 在幻读中，发现数据不一致主要是数据增多或者减少了。
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 未提交读 | 允许 | 允许 | 允许 |
| 提交读 | 不允许 | 允许 | 允许 |
| 可重复读 | 不允许 | 不允许 | 允许 |
| 串行化 | 不允许 | 不允许 | 不允许 |
DB_ROW_ID：所需空间6byte，隐含的自增的行ID，用来生成聚簇索引，如果数据表没有指定聚簇索引，InnoDB会利用这个隐藏ID创建聚簇索引。
DB_TRX_ID：所需空间6byte，最近修改的事务ID，记录创建这条记录或最后一次修改这条记录的事务ID。
DB_ROLL_PTR：所需空间7byte，回滚指针，指向这条记录的上一个版本。
它们大致长这样，省略了具体字段的值。·
从上面的分析可以看出，事务对同一记录的修改，记录的各个会在Undo日志中连接成一个线性表，在表头的就是最新的旧纪录。
在重复读的隔离级别下，InnoDB的工作流程：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 未提交读 | 允许 | 允许 | 允许 |
| 提交读 | 不允许 | 允许 | 允许 |
| 可重复读 | 不允许 | 不允许 | 允许 |
| 串行化 | 不允许 | 不允许 | 不允许 |
Before InsertAfter InsertBefore UpdateAfter UpdateBefore DeleteAfter DeleteDDL（Data Ddefinition Language） CREATE，DROP，ALTER
主要为以上操作 即对逻辑结构等有操作的，其中包括表结构，视图和索引。
DQL（Data Query Language） SELECT
这个较为好理解 即查询操作，以select关键字。各种简单查询，连接查询等 都属于DQL。
DML（Data Manipulation Language） INSERT，UPDATE，DELET
主要为以上操作 即对数据进行操作的，对应上面所说的查询操作 DQL与DML共同构建了多数初级程序员常用的增删改查操作。而查询是较为特殊的一种 被划分到DQL中。
INNER JOIN）LEFT JOIN/RIGHT JOIN）UNION与UNION ALL）FULL JOIN）CROSS JOIN）
NOT NULL: 用于控制字段的内容一定不能为空（NULL）。UNIQUE: 控件字段内容不能重复，一个表允许有多个 Unique 约束。PRIMARY KEY: 也是用于控件字段内容不能重复，但它在一个表只允许出现一个。FOREIGN KEY: 用于预防破坏表之间连接的动作，也能防止非法数据插入外键列，因为它必须是它指向的那个表中的值之一。CHECK: 用于控制字段的值范围。| Delete | Truncate | Drop | |
|---|---|---|---|
| 类型 | 属于DML | 属于DDL | 属于DDL |
| 回滚 | 可回滚 | 不可回滚 | 不可回滚 |
| 删除内容 | 表结构还在，删除表的全部或者一部分数据行 | 表结构还在，删除表中的所有数据 | 从数据库中删除表，所有的数据行，索引和权限也会被删除 |
| 删除速度 | 删除速度慢，需要逐行删除 | 删除速度快 | 删除速度最快 |
在不再需要一张表的时候，用drop； 在想删除部分数据行时候，用delete； 在保留表而删除所有数据的时候用truncate。
| 隔离级别 | 实现方式 |
|---|---|
| 未提交读 | 总是读取最新的数据，无需加锁 |
| 提交读 | 读取数据时加共享锁，读取数据后释放共享锁 |
| 可重复读 | 读取数据时加共享锁，事务结束后释放共享锁 |
| 串行化 | 锁定整个范围的键，一直持有锁直到事务结束 |
| MySQL锁类别 | 资源开销 | 加锁速度 | 是否会出现死锁 | 锁的粒度 | 并发度 |
|---|---|---|---|---|---|
| 表级锁 | 小 | 快 | 不会 | 大 | 低 |
| 行级锁 | 大 | 慢 | 会 | 小 | 高 |
| 页面锁 | 一般 | 一般 | 不会 | 一般 | 一般 |
select * from table where id=1 for update
CAS，即 Compare And Swap(比较与交换)，是一种无锁算法，基于硬件原语实现，能够在不使用锁的情况下实现多线程之间的变量同步。jdk中的java.util.concurrent.atomic包中的原子类就是通过CAS来实现了乐观锁。CAS算法过程(?） 算法涉及到三个操作数：
CAS具体执行时，当且仅当预期值A符合内存地址V中存储的值时，就用新值U替换掉旧值，并写入到内存地址V中。否则不做更新。CAS算法的运行原理如下如所示： CAS会有如下三个方面的问题： 1.ABA问题，一个线程将内存值从A改为B，另一个线程又从B改回到A。 2.循环时间长开销大：CAS算法需要不断地自旋来读取最新的内存值，长时间读取不到就会造成不必要的CPU开销。 3.只能保证一个共享变量的原子操作（jdk的AtomicReference来保证应用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作，解决了这一问题）。 ABA问题图解：
ABA问题解决方案：在变量前面添加版本号，每次变量更新的时候都将版本号加1，比如juc的原子包中的AtomicStampedReference类。
在MySQL中，MyISAM是一次获得所需的全部锁，要么全部满足，要么等待，所以不会出现死锁。 在InnoDB存储引擎中，除了单个SQL组成的事务外，锁都是逐步获得的，所以存在死锁问题。如何避免MySQL发生死锁或锁冲突：
| drop | delete | truncate | |
|---|---|---|---|
| 速度 | 快 | 逐行删除，慢 | 较快 |
| 类型 | DDL | DML | DDL |
| 回滚 | 不可回滚 | 可回滚 | 不可回滚 |
| 删除内容 | 删除整个表，数据行、索引都会被删除 | 表结构还在，删除表的一部分或全部数据 | 表结构还在，删除表的全部数据 |
slow_query_log：是否开启慢日志查询，1表示开启，0表示关闭。slow_query_log_file：MySQL数据库慢查询日志存储路径。long_query_time：慢查询阈值，当SQL语句查询时间大于阈值，会被记录在日志上。log_queries_not_using_indexes：未使用索引的查询会被记录到慢查询日志中。log_output：日志存储方式。“FILE”表示将日志存入文件。“TABLE”表示将日志存入数据库。配置项：slow_query_log可以使用show variables like ‘slov_query_log’查看是否开启， 果状态值为OFF，可以使用set GLOBAL slow_query_log = on来开启， 它会在datadir下产生一个xxx-slow.log的文件。
配置项：long_query_time查看：show VARIABLES like 'long_query_time'，单位秒 设置：set long_query_time=0.5实操时应该从长时间设置到短的时间，即将最慢的SQL优化掉
xxx-slow.log中
慢查询的优化首先要搞明白慢的原因是什么？是查询条件没有命中索引？是load了不需要的数据列？还是数据量太大？
所以优化也是针对这三个方向来的，
LIMIT 子句可以被用于强制 SELECT 语句返回指定的记录数。
LIMIT 接受一个或两个数字参数。参数必须是一个整数常量。
如果给定两个参数，
第一个参数指定第一个返回记录行的偏移量，
第二个参数指定返回记录行的最大数目。
初始记录行的偏移量是 0(而不是 1)
mysql> SELECT * FROM table LIMIT 5,10;
// 检索记录行 6-15
mysql> SELECT * FROM table LIMIT 5;
//检索前 5 个记录行
//换句话说，LIMIT n 等价于 LIMIT 0,n。
UUID：(Universally Unique Identifier）通用唯一标识码，UUID是基于当前时间、计数器和硬件标识等数据计算生成的。
使用UUID的优点：
from -> on -> join -> where -> group by -> having -> select -> distinct -> order by
主从复制的作用：
MyISAM，提升查询性能及节约系统开销slave不能写只能读
如果对方案一 使用slave执行写操作，那么show slave status将会呈现Slave_SQL_Running=NO，此时你需要按照前面提到的手动同步一下slave。
mysql-proxy代理
优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议实际生产中使用
缺点：降低性能， 不支持事务
方案二
使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。
如果采用了mybatis， 可以将读写分离放在ORM层，比如mybatis可以通过mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select都访问salve库，这样对于dao层都是透明。plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不过这样依然有一个问题， 也就是不支持事务， 所以我们还需要重写一下DataSourceTransactionManager， 将read-only的事务扔进读库， 其余的有读有写的扔进写库。
方案三
使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务.
缺点：类内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理。
我们都知道在应用sql中有一类函数叫做聚合函数,例如sum()、avg()、max()等等, 这类函数可以将多行数据按照规则聚集为一行,一般来讲聚集后的行数是要少于聚 集前的行数的。 但是有时我们想要既显示聚集前的数据,又要显示聚集后的数据, 这时我们便引入了窗口函数。 开窗函数可以为每组返回多个值，因为开窗函数所执行聚合计算的行集组是窗口。
GROUP BYTOP Npartition by）
order by）
rows between或range between）
over(partition by col1 order by col2 rows between col3)
开窗函数=分析函数+Over();
row_number() over(partition by … order by …)
rank() over(partition by … order by …)
dense_rank() over(partition by … order by …)
count() over(partition by … order by …)
max() over(partition by … order by …)
min() over(partition by … order by …)
sum() over(partition by … order by …)
avg() over(partition by … order by …)
first_value() over(partition by … order by …)
last_value() over(partition by … order by …)
lag() over(partition by … order by …)
lead() over(partition by … order by …)
开窗函数详细见：https://hiszm.blog.csdn.net/article/details/119824742
引用
https://hiszm.cn
https://hiszm.blog.csdn.net/article/details/119540143
https://mp.weixin.qq.com/s/REzOiTTNKstR1JHlu3thzQ
https://blog.csdn.net/jankin6/category_11191625.html
https://mp.weixin.qq.com/s_biz=MzU3MzgwNTU2Mg==&mid=2247487449&idx=1&sn=2cc97bf6669416267c25a7a46192b706&scene=21#wechat_redirect
我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i
有时我需要处理键/值数据。我不喜欢使用数组，因为它们在大小上没有限制(很容易不小心添加超过2个项目，而且您最终需要稍后验证大小)。此外，0和1的索引变成了魔数(MagicNumber)，并且在传达含义方面做得很差(“当我说0时，我的意思是head...”)。散列也不合适，因为可能会不小心添加额外的条目。我写了下面的类来解决这个问题:classPairattr_accessor:head,:taildefinitialize(h,t)@head,@tail=h,tendend它工作得很好并且解决了问题，但我很想知道:Ruby标准库是否已经带有这样一个类？ 最佳
我正在尝试使用Curbgem执行以下POST以解析云curl-XPOST\-H"X-Parse-Application-Id:PARSE_APP_ID"\-H"X-Parse-REST-API-Key:PARSE_API_KEY"\-H"Content-Type:image/jpeg"\--data-binary'@myPicture.jpg'\https://api.parse.com/1/files/pic.jpg用这个:curl=Curl::Easy.new("https://api.parse.com/1/files/lion.jpg")curl.multipart_form_
无论您是想搭建桌面端、WEB端或者移动端APP应用，HOOPSPlatform组件都可以为您提供弹性的3D集成架构，同时，由工业领域3D技术专家组成的HOOPS技术团队也能为您提供技术支持服务。如果您的客户期望有一种在多个平台（桌面/WEB/APP，而且某些客户端是“瘦”客户端）快速、方便地将数据接入到3D应用系统的解决方案，并且当访问数据时，在各个平台上的性能和用户体验保持一致，HOOPSPlatform将帮助您完成。利用HOOPSPlatform，您可以开发在任何环境下的3D基础应用架构。HOOPSPlatform可以帮您打造3D创新型产品，HOOPSSDK包含的技术有：快速且准确的CAD
本教程将在Unity3D中混合Optitrack与数据手套的数据流，在人体运动的基础上，添加双手手指部分的运动。双手手背的角度仍由Optitrack提供，数据手套提供双手手指的角度。 01 客户端软件分别安装MotiveBody与MotionVenus并校准人体与数据手套。MotiveBodyMotionVenus数据手套使用、校准流程参照：https://gitee.com/foheart_1/foheart-h1-data-summary.git02 数据转发打开MotiveBody软件的Streaming，开始向Unity3D广播数据；MotionVenus中设置->选项选择Unit
文章目录一、概述简介原理模块二、配置Mysql使用版本环境要求1.操作系统2.mysql要求三、配置canal-server离线下载在线下载上传解压修改配置单机配置集群配置分库分表配置1.修改全局配置2.实例配置垂直分库水平分库3.修改group-instance.xml4.启动监听四、配置canal-adapter1修改启动配置2配置映射文件3启动ES数据同步查询所有订阅同步数据同步开关启动4.验证五、配置canal-admin一、概述简介canal是Alibaba旗下的一款开源项目，Java开发。基于数据库增量日志解析，提供增量数据订阅&消费。Git地址：https://github.co
我正在尝试在Rails上安装ruby，到目前为止一切都已安装，但是当我尝试使用rakedb:create创建数据库时，我收到一个奇怪的错误:dyld:lazysymbolbindingfailed:Symbolnotfound:_mysql_get_client_infoReferencedfrom:/Library/Ruby/Gems/1.8/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundleExpectedin:flatnamespacedyld:Symbolnotfound:_mysql_get_client_infoReferencedf
文章目录1.开发板选择*用到的资源2.串口通信（个人理解）3.代码分析（注释比较详细）1.主函数2.串口1配置3.串口2配置以及中断函数4.注意问题5.源码链接1.开发板选择我用的是STM32F103RCT6的板子，不过代码大概在F103系列的板子上都可以运行，我试过在野火103的霸道板上也可以，主要看一下串口对应的引脚一不一样就行了，不一样的就更改一下。*用到的资源keil5软件这里用到了两个串口资源，采集数据一个，串口通信一个，板子对应引脚如下：串口1，TX：PA9，RX：PA10串口2，TX：PA2，RX：PA32.串口通信（个人理解）我就从串口采集传感器数据这个过程说一下我自己的理解，
SPI接收数据左移一位问题目录SPI接收数据左移一位问题一、问题描述二、问题分析三、探究原理四、经验总结最近在工作在学习调试SPI的过程中遇到一个问题——接收数据整体向左移了一位（1bit）。SPI数据收发是数据交换，因此接收数据时从第二个字节开始才是有效数据，也就是数据整体向右移一个字节（1byte）。请教前辈之后也没有得到解决，通过在网上查阅前人经验终于解决问题，所以写一个避坑经验总结。实际背景：MCU与一款芯片使用spi通信，MCU作为主机，芯片作为从机。这款芯片采用的是它规定的六线SPI，多了两根线：RDY和INT，这样从机就可以主动请求主机给主机发送数据了。一、问题描述根据从机芯片手
前言一般来说，前端根据后台返回code码展示对应内容只需要在前台判断code值展示对应的内容即可，但要是匹配的code码比较多或者多个页面用到时，为了便于后期维护，后台就会使用字典表让前端匹配，下面我将在微信小程序中通过wxs的方法实现这个操作。为什么要使用wxs？{{method(a,b)}}可以看到，上述代码是一个调用方法传值的操作，在vue中很常见，多用于数据之间的转换，但由于微信小程序诸多限制的原因，你并不能优雅的这样操作，可能有人会说，为什么不用if判断实现呢？但是if判断的局限性在于如果存在数据量过大时，大量重复性操作和if判断会让你的代码显得异常冗余。wxswxs相当于是一个独立