① 内存条存储数据的原理
内存的存储原理
内存，英文名为RAM(Random Access Memory)，全称是随机存取存储器。主要的作用就是存储代码和数据供CPU在需要的时候调用。但是这些数据并不是像用木桶盛水那么简单，而是类似图书馆中用有格子的书架存放书籍一样，不但要放进去还要能够在需要的时候准确的调用出来，虽然都是书但是每本书是不同的。对于内存等存储器来说也是一样的，虽然存储的都是代表0和1的代码，但是不同的组合就是不同的数据。让我们重新回到书和书架上来。
如果有一个书架上有10行和10列格子(每行和每列都有0～9编号)，有100本书要存放在里面，那么我们使用一个行的编号和一个列的编号就能确定某一本书的位置。如果已知这本书的编号36，那么我们首先锁定第3行，然后找到第6列就能准确的找到这本书了。
在内存中也是利用了相似的原理现在让我们回到内存上，对于它而言数据总线是用来传入数据或者传出数据的。因为存储器中的存储空间是如果前面提到的存放图书的书架一样通过一定的规则定义的，所以我们可以通过这个规则来把数据存放到存储器上相应的位置，而进行这种定位的工作就要依靠地址总线来实现了。
对于CPU来说，内存就像是一条长长的有很多空格的“线”，每个空格都有一个唯一的地址与之相对应。如果CPU想要从内存中调用数据，它首先需要给地址总线发送地址数据定位要存取的数据，然后等待若干个时钟周期之后，数据总线就会把数据传输给CPU。当地址解码器接收到地址总线送来的地址数据之后，它会根据这个数据定位CPU想要调用的数据所在的位置，然后数据总线就会把其中的数据传送到CPU。
CPU在一行数据中每次知识存取一个字节的数据。会到实际中，通常CPU每次需要调用64bit或者是128bit的数据(单通道内存控制器为64bit，双通道为128bit)。如果数据总线是64bit的话，CPU就会在一个时间中存取8个字节的数据，因为每次还是存取1个字节的数据，64bit总线将不会显示出来任何的优势，工作的效率将会降低很多。这也就是现在的主板和CPU都使用双通道内存控制器的原因。
② 分析大文本与图像数据在数据库内部的存储原理。
图像数据在数据库内部的存储原理:
XML 是文本型的数据交换结构，对于字符类型的文本交换非常的方便，实际工作中我们往往需要通过 XML 将二进制格式的图形图像信息数据进行数据交换。本文从介绍 BASE64 编码的原理入手，通过采用 C 语言编写 DB2 的嵌入存储过程，实现了在数据库内存中将文本格式的图片文件到二进制 BLOB 字段之间的转换，并且就性能优化等提出若干建议，该设计思路和程序可以广泛的应用到图像图形数据在 XML 的存储和转换。
--------------------------------------------------------------------------------
回页首
XML 存储图形图像的基本原理
XML 作为一种非常广泛的数据交换的载体被广泛的应用到了各行各业的数据交换中。对于图形图像数据的转换，需要采用 Base64 编码将二进制格式的图形图像信息转换成文本格式再进行传输。
Base64 编码转换的思想是通过 64 个 ASCII 字符码对二进制数据进行重新编码组合，即将需要转换的数据每三个字节（24 位）为一组，再将这 24 位数据按每组 6 位进行重新划分，在每组的最高 2 位填充 0 最终成一个完整的 8 位字节。如果所要编码的数据的字节数不是 3 的整数倍，需要在最后一组数据填充 1 到 2 个字节的 0 字节。例如：我们对 ABC 进行 BASE64 的编码，ABC 的编码值：A(65), B(66), C(67)。再取二进制 A（01000001）B（01000010）C（01000011）连接起来构成 010000010100001001000011，然后按 6 位为单位分成 4 个数据块并在最高位填充两个 0 后形成 4 个字节的编码后的值（00010000）（00010100）（00001001）（00000011）。再将 4 个字节的数据转换成十进制数为（16）（20）（19）（3）。最后根据 BASE64 给出的 64 个基本字符表，查出对应的 ASCII 码字符（Q）（U）（J）（D）。这里的值实际就是数据在字符表中的索引。
BASE64 字符表：
。
某项目的数据交换采用 XML 的为介质，XML 的结构包括个人基本信息：姓名、性别、相片等信息，其中相片信息是采用经过 BASE64 函数转换后的文本型数据，图像图形信息通过 BASE64 进行数据转换后，形成文本格式的数据类型，再将相应的数据存放到 XML 中，最终形成可供交换的文本型的 XML 数据结构。
XML 的数据结构如下所示：
<?xml version=”1.0” encoding=”UTF-8” ?>
<HeadInfo>
<TotalNum>10<TotalNum>
<TransDate>2007-10-18</TransDate>
</HeadInfo>
<Data>
<Name> 张三 </Name>
<Sex> 男 </Sex>
<Photo>/9j/4AAQSkZJRgABAQAAAQABAAD......</Photo>
<Data>
--------------------------------------------------------------------------------
回页首
相片数据在 DB2 嵌入式 C 程序的实现方法
该项目要求能够在 DB2 数据库中将相片数据存储为二进制 BLOB 格式。我们采用 DATASTAGE 进行 XML 数据加载，将 XML 中的姓名、性别等基本数据项加载到相应的字段，其中文本型的相片数据则加载到 CLOB 字段中，再按照 BASE64 的编码规则进行逆向转码，整个数据流程如下图所示：
图 1. 相片存储流程图
用户的相片每天的更新数据为 30 万条，而且每个相片的平均大于 32KB，为了获得最佳的数据库性能，选择采用 C 存储过程的方式开发了 BASE64 的转换函数。每次函数读取存储在 CLOB 字段的文本格式数据全部存储到内存中，并且通过 decode 函数在内存中进行转码，转码后再存入数据库中。
程序的清单 1 是逐行读取 CLOB 字段，并且调用 decode 函数进行转码；程序的清单 2 是 decode 函数的关键性代码。完整的程序见源代码下载部分。
清单 1. 读入 CLOB，写入 BLOB 字段
EXEC sql BEGIN DECLARE SECTION;
SQL TYPE IS CLOB(100 K) clobResume; //CLOB 结构体变量
SQL TYPE IS BLOB(100 K) blobResume; //BLOB 结构体变量
sqlint16 bobind;
sqlint16 lobind;
sqlint16 cobind;
sqlint32 idValue;
EXEC SQL END DECLARE SECTION;
int clob2bin(void)
{
// 声明 SQLCA 结构
struct sqlca sqlca;
int charNb;
int lineNb;
long n;
n=0;
// 定义数据库游标
EXEC SQL DECLARE c1 CURSOR WITH HOLD FOR
SELECT czrkxp_a
FROM CZRK_blob for update;
EXEC SQL OPEN c1;
// 活动 CLOB 字段的信息，已经 CLOB 字段的大小
EXEC SQL FETCH c1 INTO :clobResume:cobind;
// 循环读取 CLOB 字段，并且调用 DECODE 转码函数
while (sqlca.sqlcode != 100)
{
if (cobind < 0)
{
printf(“ NULL LOB indicated.\n”);
}
else
{
n++;
decode(); // 文本格式到二进制流的转码函数
printf(“\nCurrent Row =%ld”,n);
// 数据写入 BLOB 字段
EXEC SQL update czrk_blob set czrkxp_blob = :blobResume
where current of c1; ;
// 提交事务
EXEC SQL COMMIT;
}
EXEC SQL FETCH c1 INTO :clobResume:cobind ;
}
// 关闭游标
EXEC SQL CLOSE c1;
EXEC SQL COMMIT;
return 0;
}
清单 2. 文本文件到二进制文件的转换
void decode( void )
{
unsigned char in[4], out[3], v;
int I, len;
long j,k;
j = -1;
k=0;
// 将读入 CLOB 结构体变量的数据进行转换
while( j < clobResume.length){
for( len = 0, I = 0; I < 4 && ( j < clobResume.length ); i++ ) {
v = 0;
while((j < clobResume.length) && v == 0 ) {
j++;
v = (unsigned char) clobResume.data[j];
v = (unsigned char) ((v < 43 || v > 122) ? 0 : cd64[ v – 43 ]);
if( v ) {
v = (unsigned char) ((v == ‘$’) ? 0 : v – 61);
}
}
if( j < clobResume.length ) {
len++;
if( v ) {
in[ I ] = (unsigned char) (v – 1);
}
}
else {
in[i] = 0;
}
}
if( len ) {
decodeblock( in, out );
// 写入到 BLOB 结构体变量中
for( I = 0; I < len – 1; i++ ) {
blobResume.data[k] = out[i];
k++;
}
}
}
blobResume.length= k;
}
--------------------------------------------------------------------------------
回页首
数据的转换效率和优化建议
在 IBM P570 数据库服务器上运行，该程序的运行效率非常高，先后进行了几个数量级的测试，最终平均测试的转换效率为：每 1 万笔数据记录，转换的效率 55 秒，即 182 条 / 秒。值得注意的是，整个转换过程占用 CPU 的量并不特别大，主要的性能瓶颈在磁盘阵列中。
以后可以进一步在以下方面进行调优，确保程序转换的效率更高：
1）采用多进程调用的方式，以获得更高的并发数量；
2）采用每 10 次或者 100 次提交事务的方式，减少访问磁盘的次数；
3）将 CLOB 和 BLOB 分别放置在不同的表空间上，并且将表空间分布在在多个磁盘上，获得最佳的磁盘访问速度。
③ 请教一下，数据库加密的原理是什么
数据库加密乱塌的底层原理本质上是TDE(Transparent Data Encryption)技术，即一种透明数据加密技术，在数据库主程序启动时加载扩展的TDE插件。TDE插件技术可以实现：在写入存储介质前将数据加密，返岁实现数据的存储加密；在从存储介质加载数据到内存前进行数据解密，实现数据的解密使用；利用TDE插件的增强访问控制能力实现独立于数据库原漏陪睁有权限体系的增强的权控功能。安华金和数据库加密产品就是依托这种技术实现的，想要了解更多，找他们咨询一下吧。可以去上网络看看。
④ memsql数据库操作
1、memsql 分布式内存数据库瞎凳键，号称是速度最快的关系数据库。由前Facebook工程师磨巧创建，兼容MySQL，但比MySQL快30倍，能实现每秒150万次事务。原理是仅用内存并将SQL预编译为C++。
2、你的问题，memsql 是怎么保证数据存入没错，这是数据库的基本功能，保证数据的保存和读取，这是通过数据库事务、以及锁功能来实现的，具体的原理阐述请查阅数据库基础书籍。
3、希望对你有帮助。祝粗指你学有所得。
⑤ 搞软件开发，请你来谈谈数据库连接池的原理吧
这次我们采取技术演进的方式来谈谈数据库连接池的技术出现过程及其原理，以及当下最流行的开源数据库连接池jar包。
1、原理
一般来说，Java应用程序访问数据库的过程是 ：
①装载数据库驱动程序；
②通过jdbc建立数据库连接；
③访问数据库，执行sql语句；
④断开数据库连接。
2、代码
3、分析
程序开发过程中，存在很多问题：首先，每一次web请求都要建立一次数据库连接。建立连接是一个费时的活动，每次都得花费0.05s～1s的时间，而且系统还要分配内存资源。这个时间对于一次或几次数据库操作，或许感觉不出系统有多大的开销。可是对于现在的web应用，尤其是大型电子商务网站，同时有几百人甚至几千人在线是很正常的事。在这种情况下，频繁的进行数据库连接操作势必占用很多的系统资源，网站的响应速度必定下降，严重的甚至会造成服务器的崩溃。不是危言耸听，这就是制约某些电子商务网站发展的技术瓶颈问题。其次，对于每一次数据库连接，使用完后都得断开。否则，如果程序出现异常而未能关闭，将会导致数据库系统中的内存泄漏，最终将不得不重启数据库。还有，这种开发不能控制被创建的连接对象数，系统资源会被毫无顾及的分配出去，如连接过多，也可能导致内存泄漏，服务器崩溃。
上述的用户查询案例，如果同时有1000人访问，就会不断的有数据库连接、断开操作：
通过上面的分析，我们可以看出来，“数据库连接”是一种稀缺的资源，为了保障网站的正常使用，应该对其进行妥善管理。其实我们查询完数据库后，如果不关闭连接，而是暂时存放起来，当别人使用时，把这个连接给他们使用。就避免了一次建立数据库连接和断开的操作时间消耗。原理如下：
由上面的分析可以看出，问题的根源就在于对数据库连接资源的低效管理。我们知道，对于共享资源，有一个很着名的设计模式：资源池（resource pool）。该模式正是为了解决资源的频繁分配﹑释放所造成的问题。为解决上述问题，可以采用数据库连接池技术。数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”。预先在缓冲池中放入一定数量的连接，当需要建立数据库连接时，只需从“缓冲池”中取出一个，使用完毕之后再放回去。我们可以通过设定连接池最大连接数来防止系统无尽的与数据库连接。更为重要的是我们可以通过连接池的管理机制监视数据库的连接的数量﹑使用情况，为系统开发﹑测试及性能调整提供依据。
我们自己尝试开发一个连接池，来为上面的查询业务提供数据库连接服务：
① 编写class 实现DataSource 接口
② 在class构造器一次性创建10个连接，将连接保存LinkedList中
③ 实现getConnection 从 LinkedList中返回一个连接
④ 提供将连接放回连接池中方法
1、连接池代码
2、使用连接池重构我们的用户查询函数
这就是数据库连接池的原理，它大大提供了数据库连接的利用率，减小了内存吞吐的开销。我们在开发过程中，就不需要再关心数据库连接的问题，自然有数据库连接池帮助我们处理，这回放心了吧。但连接池需要考虑的问题不仅仅如此，下面我们就看看还有哪些问题需要考虑。
1、并发问题
为了使连接管理服务具有最大的通用性，必须考虑多线程环境，即并发问题。这个问题相对比较好解决，因为java语言自身提供了对并发管理的支持，使用synchronized关键字即可确保线程是同步的。使用方法为直接在类方法前面加上synchronized关键字，如：
2、多数据库服务器和多用户
对于大型的企业级应用，常常需要同时连接不同的数据库（如连接oracle和sybase）。如何连接不同的数据库呢？我们采用的策略是：设计一个符合单例模式的连接池管理类，在连接池管理类的唯一实例被创建时读取一个资源文件，其中资源文件中存放着多个数据库的url地址等信息。根据资源文件提供的信息，创建多个连接池类的实例，每一个实例都是一个特定数据库的连接池。连接池管理类实例为每个连接池实例取一个名字，通过不同的名字来管理不同的连接池。
对于同一个数据库有多个用户使用不同的名称和密码访问的情况，也可以通过资源文件处理，即在资源文件中设置多个具有相同url地址，但具有不同用户名和密码的数据库连接信息。
3、事务处理
我们知道，事务具有原子性，此时要求对数据库的操作符合“all-all-nothing”原则即对于一组sql语句要么全做，要么全不做。
在java语言中，connection类本身提供了对事务的支持，可以通过设置connection的autocommit属性为false 然后显式的调用commit或rollback方法来实现。但要高效的进行connection复用，就必须提供相应的事务支持机制。可采用每一个事务独占一个连接来实现，这种方法可以大大降低事务管理的复杂性。
4、连接池的分配与释放
连接池的分配与释放，对系统的性能有很大的影响。合理的分配与释放，可以提高连接的复用度，从而降低建立新连接的开销，同时还可以加快用户的访问速度。
对于连接的管理可使用空闲池。即把已经创建但尚未分配出去的连接按创建时间存放到一个空闲池中。每当用户请求一个连接时，系统首先检查空闲池内有没有空闲连接。如果有就把建立时间最长（通过容器的顺序存放实现）的那个连接分配给他（实际是先做连接是否有效的判断，如果可用就分配给用户，如不可用就把这个连接从空闲池删掉，重新检测空闲池是否还有连接）；如果没有则检查当前所开连接池是否达到连接池所允许的最大连接数（maxconn）如果没有达到，就新建一个连接，如果已经达到，就等待一定的时间（timeout）。如果在等待的时间内有连接被释放出来就可以把这个连接分配给等待的用户，如果等待时间超过预定时间timeout 则返回空值（null）。系统对已经分配出去正在使用的连接只做计数，当使用完后再返还给空闲池。对于空闲连接的状态，可开辟专门的线程定时检测，这样会花费一定的系统开销，但可以保证较快的响应速度。也可采取不开辟专门线程，只是在分配前检测的方法。
5、连接池的配置与维护
连接池中到底应该放置多少连接，才能使系统的性能最佳？系统可采取设置最小连接数（minconn）和最大连接数（maxconn）来控制连接池中的连接。最小连接数是系统启动时连接池所创建的连接数。如果创建过多，则系统启动就慢，但创建后系统的响应速度会很快；如果创建过少，则系统启动的很快，响应起来却慢。这样，可以在开发时，设置较小的最小连接数，开发起来会快，而在系统实际使用时设置较大的，因为这样对访问客户来说速度会快些。最大连接数是连接池中允许连接的最大数目，具体设置多少，要看系统的访问量，可通过反复测试，找到最佳点。
如何确保连接池中的最小连接数呢？有动态和静态两种策略。动态即每隔一定时间就对连接池进行检测，如果发现连接数量小于最小连接数，则补充相应数量的新连接以保证连接池的正常运转。静态是发现空闲连接不够时再去检查。
理解了连接池的原理就可以了，没有必要什么都从头写一遍，那样会花费很多时间，并且性能及稳定性也不一定满足要求。事实上，已经存在很多流行的性能优良的第三方数据库连接池jar包供我们使用。如：
其中c3p0已经很久没有更新了。DBCP更新速度很慢，基本处于不活跃状态，而Druid和HikariCP处于活跃状态的更新中。
⑥ 面试中问到Redis持久化的原理，本篇在做详细解答
我们知道redis是一个 高效的分布式内存数据库 ，由于是操作内存所以性能非常之快，通常用它来做分布式缓存，用来提高微服务的高性能，但是因为是内存操作，所以当出现服务器故障，断电等情况就会造成 内存数据丢失 ，不可恢复，因此redis 引入了持久化机制来将内存数据写入圆带磁盘，从而保障了Redis的数据不被丢失。
Redis有两种持久化的方式，一种是RDB，另外种是AOF。
RDB是将Redis内存中数据的快照存储在磁盘内，是Redis的默认持久化方案。
RDB持久化默认有三种策略
可在redis.conf中配置，会以一段时间内达到指定修改的次数为规则来触发快照操作，快照文件名为mp.rdb。每当Redis服务重启的时候都会从该文件中把数据加载到内存中。
在60秒内有10000次操作即触发RDB持久化。
没有满足第一种条件时，在900秒内有1次操作即触发RDB持久化。
没有满足第二种条件时，在300秒内有10次操作即触发RDB持久化。
RDB持久化除了可以根据配置中的策略来触发外，还可以使用save和bgsave命令手动来触发。这两个命令的区别在于save会阻塞服务器进程。在执行save命令的过程中，服务器不能处理任何请求，但是bgsave（background save，后台保存）命令会通过一个子进程在后台处理数据RDB持久化。本质上save和bgsave调用的都是rdbSave函数，所以Redis不允许save和bgsave命令同时执行，当然这也是为了避免RDB文件数据出现不一致性的问题。
每次都是一个大文件，备份写入IO操作笔记大，很容易耗时，影响进程资源使用。
如果最近一次进程崩溃，那么最近一次数据备份后的数据就被丢失。
文件直接就可以当冷备使用
AOF（Append Only File）以独立日志的方式记录每次的写命令，可以很好地解决了数据持久化的实时性。系统重启时可以重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加亩饥在AOF缓冲区，然后根据对应策略写入硬盘。
AOF的实现流程有三个步骤
步骤一
把命令追加到AOF缓冲区，
步骤二
将缓冲区的内容写入程序缓冲区
步骤三
将程序缓冲区的内容写入文件
当AOF持久化功能处于开启状态时，服务器每执行完一个命令就会将命令以迅腔返协议格式追加写入redisServer结构体的aof_buf缓冲区。而在服务重启的时候会把AOF文件加载到缓冲区中。
AOF有 三种触发机制
·always：每次发生数据变更都会被立即记录到磁盘，性能较差，但数据完整性比较好。
·everysec：每秒钟将aof_buf缓冲区的内容写入AOF文件，如果宕机，就会有1秒内的数据丢失。
·no：将数据同步操作交给操作系统来处理，性能最好，但是数据可靠性最差。在配置文件中设置appendonly=yes后，若没有指定apendfsync，默认会使用everysec选项。
写入指令随着时间的推移，记录了很多重复的指令，导致数据量非常大。
RDB优先级高于AOF
RDB小，AOF较大
RDB慢，AOF快
RDB快，AOF慢
⑦ sqlitememory原理
SQLite创建的数据库有一种模式IN-MEMORY，但是它并不表示SQLite就成了一个内存数据库。IN-MEMORY模式可以简单地理解为，（2020 表述勘误：本来创建的数据库文件是基于磁盘的，现在整个文件使用内存空间来代替磁盘空间，没有了文件作为backingstore，不必在修改数据库后将缓存页提交到文件系统），其它操作保持一致。也就是数据库的设计没有根本改变。
inmemory与tempdb是两种节约模式，节约的对象为（rollback）日志文件以及数据库文件，减少IO。inmemory将日志写在内存，并且去除数据库文件作为backingStore，缓存页不用提交到文件系统。tempdb只会在只会在脏的缓存页超过当前总量的25％才会同步刷写到文件，换句话说在临时数据库模式下，事务提交时并不总同步脏页，因此减少了IO数量，事务日志也受这种机制影响，所以在临时数据库模式下，事务日志是不是MEMORY并不重要。回过头来看，内存模式则是临时模式的一种极致，杜绝所有的IO。这两种模式都只能存在一个sqlite3连接，关闭时销毁。
提到内存，许多人就会简单地理解为，内存比磁盘速度快很多，所以内存模式比磁盘模式的数据库速度也快很多，甚至有人望文生意就把它变成等同于内存数据库。
它并不是为内存数据库应用而设计的，本质还是文件数据库。它的数据库存储文件有将近一半的空间是空置的，这是它的B树存储决定的，（2020 勘误：对于固定长度记录，页面使用率最大化，对于非自增计数键的索引，页面一般会保留20～扒袜60％的空间，方便插入）请参看上一篇SQLite存储格式。内春睁激存模式只是将数据库存储文件放入内存空间，但并不考虑最有效管理你的内存空间，其它临时文件也要使用内存，事务回滚日志一样要生成，只是使用了内存空间。它的作用应该偏向于临时性的用途。
（2020 补充：下面的测试有局限性，）
我们先来看一下下面的测试结果，分别往memory和disk模式的sqlite数据库进行1w, 10w以及100w条数据的插入，采用一次性提交事务。另外使用commit_hook捕捉事务提交次数。
（注：测试场景为早袭在新建的数据库做插入操作，所以回滚日志是很小的，并且无需要在插入过程中查找而从数据库加载页面，因此测试也并不全面）
内存模式
磁盘模式
在事务提交前的耗时 (事务提交后的总耗时)：
1w 10w 100w
内存模式 0.04s 0.35s 3.60s
磁盘模式 0.06s (0.27s) 0.47s (0.72s) 3.95s (4.62s)
可以看到当操作的数据越少时，内存模式的性能提高得越明显，事务IO的同步时间消耗越显注。
上图还有一组数据比较，就是在单次事务提交中，如果要为每条插入语句准备的话
1w 10w 100w
内存模式 0.19s 1.92s 19.46s
磁盘模式 0.21s (0.35s) 2.06s (2.26s) 19.88s (20.41s)
我们从SQLite的设计来分析，一次插入操作，SQLite到底做了些什么。首先SQLite的数据库操作是以页面大小为单位的。在单条记录插入的事务中，回滚日志文件被创建。在B树中查找目标页面，要读入一些页面，然后将目标页面以及要修改的父级页面写出到回滚日志。操作目标页面的内存映像，插入一条记录，并在页面内重排序（索引排序，无索引做自增计数排序，参看上一篇《SQLite数据库存储格式》）。最后事务提交将修改的页面写出到数据库文件，成功后再删除日志文件。在这过程中显式进行了2次写磁盘（1次写日志文件，1次同步写数据库），还有2次隐式写磁盘（日志文件的创建和删除），这是在操作目录节点。以及为查找加载的页面读操作。更加详细可以参看官方文档的讨论章节《Atomic Commit In SQLite》。
如果假设插入100条记录，每条记录都要提交一次事务就很不划算，所以需要批量操作来减少事务提交次数。假设页面大小为4KB，记录长度在20字节内，每页可放多于200条记录，一次事务提交插入100条记录，假设这100条记录正好能放入到同一页面又没有产生页面分裂，这样就可以在单条记录插入事务的IO开销耗损代价中完成100条记录插入。
当我们的事务中，插入的数据越多，事务的IO代价就会摊得越薄，所以在插入100w条记录的测试结果中，内存模式和磁盘模式的耗时都十分接近。实际应用场合中也很少会需要一次插入100w的数据。有这样的需要就不要考虑SQLite。
（补充说明一下，事务IO指代同步数据库的IO，以及回滚日志的IO，只在本文使用）
除了IO外，还有没有其它地方也影响着性能。那就是语句执行。其实反观一切，都是在对循环进行优化。
for (i = 0; i < repeat; ++i)
{
exec("BEGIN TRANS");
exec("INSERT INTO ...");
exec("END TRANS");
}
批量插入：
exec("BEGIN TRANS");
for (i = 0; i < repeat; ++i)
{
exec("INSERT INTO ...");
}
exec("END TRANS");
当我们展开插入语句的执行
exec("BEGIN TRANS");
for (i = 0; i < repeat; ++i)
{
// unwind exec("INSERT INTO ...");
prepare("INSERT INTO ...");
bind();
step();
finalize();
}
exec("END TRANS");
又发现循环内可以移出部分语句
exec("BEGIN TRANS");
// unwind exec("INSERT INTO ...");
prepare("INSERT INTO ...");
for (i = 0; i < repeat; ++i)
{
bind();
step();
}
finalize();
exec("END TRANS");
这样就得到了批量插入的最终优化模式。
所以对sql语句的分析，编译和释放是直接在损耗CPU，而同步IO则是在饥饿CPU。
请看下图
分别为内存模式1w和10w两组测试，每组测试包括4项测试
1.只编译一条语句，只提交一次事务
2.每次插入编译语句，只提交一次事务
3.只编译一条语句，但使用自动事务。
4.每次插入编译语句，并使用自动事务。
可以看到测试项目4基本上就是测试项目2和测试项目3的结果的和。
测试项目1就是批量插入优化的最终结果。
下面是探讨内存模式的使用：
经过上面的分析，内存模式在批量插入对比磁盘模式提升不是太显注的，请现在开始关注未批量插入的结果。
下面给出的是磁盘模式0.1w和0.2w两组测试，每组测试包括4项测试
可以看到在非批量插入情况，sqlite表现很差要100秒来完成1000次单条插入事务，但绝非sqlite很吃力，因为cpu在空载，IO阻塞了程序。
再来看内存模式20w测试
可以看到sqlite在内存模式，即使在20w次的单条插入事务，其耗时也不太逊于磁盘模式100w插入一次事务。
0.1w 0.2w 20w
内存模式（非批量插入） 15.87s
磁盘模式（非批量插入） 97.4s 198.28s
编译1次插入语句 每次插入编译1次语句
内存模式（20w，20w次事务） 11.10s 15.87s
磁盘模式（100w，1次事务） 4.62s 20.41s
⑧ 数据库中多表连接的原理实现
多变关联的实现方式有hash join,merge join,nested loop join 方式，具体使用那种内型的连接，主要依据:
1.当前的优化器模式（all_rows和rule)
2.取决于表的大小
3.取决于关联字段是否有索性
4.取决于关联字段是否排序
Hash join散列连接，优化器选择较小的表（数闷扰据量少的表)利用连接键(join key)在内存中建立散列表，将数据存储到hash列表中，然后扫描较大的表
select A.*,B.* from A left join B on a.id=b.id。
先是从A表读取一条记录，用on条件匹配B表的记录，行成n行（包括重复行）如果B表没有与匹配的数据，则select中B表的字段显示为空,接着读取A表的下一条记录，right join类似。
left join基本是A表全部扫描，在表关键中不建议使用子查询作为副表，比如select A.*,B.*from A left join (select * from b where b.type=1 )这样A表是全表扫描，B表也是全表扫描。若果查询慢，可以考虑关联的字段都建索引，将不必要的排序去掉，排序会导致运行慢很多。明晌
主副表条件过滤:
table a(id, type):
id type
----------------------------------
1 1
2 1
3 2
表b结构和数据
table b(id, class):
id class
---------------------------------
1 1
2 2
Sql语句1: select a.*, b.* from a left join b on a.id = b.id and a.type = 1;
执行结果为:
a.id a.type b.id b.class
----------------------------------------
1 1 1 1
2 1 2 2
3 2
a.type=1没有起作用
sql语句2：
select a.*, b.* from a left join b on a.id = b.id where a.type = 1;
执行结果为:
a.id a.type b.id b.class
----------------------------------------
1 1 1 1
2 1 2 2
sql语句3：
select a.*, b.* from a left join b on a.id = b.id and b.class = 1;
执行结果为：
a.id a.type b.id b.class
----------------------------------------
1 1 1 1
2 1
3 2
b.class=1条件过滤成蚂槐旦功。
结论:left join中，左表（主表）的过滤条件在on后不起作用，需要在where中添加。右表（副表）的过滤条件在on后面起作用。
Mysql join原理:
Mysql join采用了Nested Loop join的算法，
＃＃＃坐车 回去补充。
⑨ 内存的工作原理
内存工作原理
1.内存寻址手衡或
首先，内存从CPU获得查找某个数据的指令，然后再找出存取资料的位置时（这个动作称为“寻址”），它先定出横坐标（也就是“列地址”）再定出纵坐标（也就是“行地址”），这就好像在地图上画个十字标记一毕伍样，非常准确地定出这个地方。对于电脑系统而言，找出这个地方时还必须确定是否位置正确，因此电脑还必须判读该地址的信号，横坐标有横坐标的信号（也就是RAS信号，Row Address Strobe）纵坐标有纵坐标的信号（也就是CAS信号，Column Address Strobe），最后再进行读或写的动作。因此，内存在读写时至少必须有五个步骤：分别是画个十字（内有定地址两个操作以及判读地址两个信号，共四个操作）以及或读或写的操作，才能完成内存的存取操作。
2.内存传输
为了储存资料，或者是从内存内部读取资料，CPU都会为这些读取或写入的资料编上地址（也就是我们所说的十字寻址方式），这个时候，CPU会通过地址总线（Address Bus）将地址送到内拦陆存，然后数据总线（Data Bus）就会把对应的正确数据送往微处理器，传回去给CPU使用。
3.存取时间
所谓存取时间，指的是CPU读或写内存内资料的过程时间，也称为总线循环（bus cycle）。以读取为例，从CPU发出指令给内存时，便会要求内存取用特定地址的特定资料，内存响应CPU后便会将CPU所需要的资料送给CPU，一直到CPU收到数据为止，便成为一个读取的流程。因此，这整个过程简单地说便是CPU给出读取指令，内存回复指令，并丢出资料给CPU的过程。我们常说的6ns（纳秒，秒－9）就是指上述的过程所花费的时间，而ns便是计算运算过程的时间单位。我们平时习惯用存取时间的倒数来表示速度，比如6ns的内存实际频率为1／6ns＝166MHz（如果是DDR就标DDR333，DDR2就标DDR2 667）。
4.内存延迟
内存的延迟时间(也就是所谓的潜伏期，从FSB到DRAM)等于下列时间的综合：FSB同主板芯片组之间的延迟时间(±1个时钟周期)，芯片组同DRAM之间的延迟时间(±1个时钟周期)，RAS到CAS延迟时间：RAS(2-3个时钟周期,用于决定正确的行地址)，CAS延迟时间 (2-3时钟周期,用于决定正确的列地址)，另外还需要1个时钟周期来传送数据，数据从DRAM输出缓存通过芯片组到CPU的延迟时间(±2个时钟周期)。一般的说明内存延迟涉及四个参数CAS（Column Address Strobe 行地址控制器）延迟，RAS（Row Address Strobe列地址控制器）－to－CAS延迟，RAS Precharge（RAS预冲电压）延迟，Act-to-Precharge（相对于时钟下沿的数据读取时间）延迟。其中CAS延迟比较重要，它反映了内存从接受指令到完成传输结果的过程中的延迟。大家平时见到的数据3—3—3—6中，第一参数就是CAS延迟（CL＝3）。当然，延迟越小速度越快。
⑩ 数据库索引的实现原理
数据库索引的实现原理
一、概述数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用(指向)数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。其实说穿了，索引问题就是一个查找问题。二、索引的原理当我们的业务产生了大量的数据时，查找数据的效率问题也就随之而来，所以我们可以通过为表设置索引，而为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址(注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的)。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)的复杂度内获取到相应数据。索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度;在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构;在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度;在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的;在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间;在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。创建索引可以大大提高系统的性能第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。第四，在使用分组和排序子句进行数据检索时，同样可以显着减少查询中分组和排序的时间。第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢?因为，增加索引也有许多不利的方面。创建索引的弊端第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。三、索引的类型根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。唯一索引唯一索引是不允许其中任何两行具有相同索引值的索引。当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。主键索引数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。聚集索引在聚集索引中，表中行的物理顺序与键值的逻辑(索引)顺序相同。一个表只能包含一个聚集索引。如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。四、局部性原理与磁盘预读由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中着名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高(不需要寻道时间，只需很少的旋转时间)，因此对于具有局部性的程序来说，预读可以提高I/O效率。预读的长度一般为页(page)的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页(在许多操作系统中，页得大小通常为4k)，主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。五、B树和B+树数据结构1、B树B树中每个节点包含了键值和键值对于的数据对象存放地址指针，所以成功搜索一个对象可以不用到达树的叶节点。成功搜索包括节点内搜索和沿某一路径的搜索，成功搜索时间取决于关键码所在的层次以及节点内关键码的数量。在B树中查找给定关键字的方法是：首先把根结点取来，在根结点所包含的关键字K1,…,kj查找给定的关键字(可用顺序查找或二分查找法)，若找到等于给定值的关键字，则查找成功;否则，一定可以确定要查的关键字在某个Ki或Ki+1之间，于是取Pi所指的下一层索引节点块继续查找，直到找到，或指针Pi为空时查找失败。2、B+树B+树非叶节点中存放的关键码并不指示数据对象的地址指针，非也节点只是索引部分。所有的叶节点在同一层上，包含了全部关键码和相应数据对象的存放地址指针，且叶节点按关键码从小到大顺序链接。如果实际数据对象按加入的顺序存储而不是按关键码次数存储的话，叶节点的索引必须是稠密索引，若实际数据存储按关键码次序存放的话，叶节点索引时稀疏索引。B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。所以 B+树有两种搜索方法：一种是按叶节点自己拉起的链表顺序搜索。一种是从根节点开始搜索，和B树类似，不过如果非叶节点的关键码等于给定值，搜索并不停止，而是继续沿右指针，一直查到叶节点上的关键码。所以无论搜索是否成功，都将走完树的所有层。B+ 树中，数据对象的插入和删除仅在叶节点上进行。这两种处理索引的数据结构的不同之处：1、B树中同一键值不会出现多次，并且它有可能出现在叶结点，也有可能出现在非叶结点中。而B+树的键一定会出现在叶结点中，并且有可能在非叶结点中也有可能重复出现，以维持B+树的平衡。2、因为B树键位置不定，且在整个树结构中只出现一次，虽然可以节省存储空间，但使得在插入、删除操作复杂度明显增加。B+树相比来说是一种较好的折中。3、B树的查询效率与键在树中的位置有关，最大时间复杂度与B+树相同(在叶结点的时候)，最小时间复杂度为1(在根结点的时候)。而B+树的时候复杂度对某建成的树是固定的。六、B/+Tree索引的性能分析到这里终于可以分析B-/+Tree索引的性能了。上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析，根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。B-Tree中一次检索最多需要h-1次I/O(根节点常驻内存)，渐进复杂度为O(h)=O(logdN)。一般实际应用中，出度d是非常大的数字，通常超过100，因此h非常小(通常不超过3)。而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点(父子)物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。综上所述，用B-Tree作为索引结构效率是非常高的。