复制表结构和数据的SQL语句

1.复制表结构及数据到新表
CREATE TABLE 新表
SELECT * FROM 旧表

2.只复制表结构到新表
CREATE TABLE 新表
SELECT * FROM 旧表 WHERE 1=2
即:让WHERE条件不成立.
CREATE TABLE 新表
LIKE 旧表

3.复制旧表的数据到新表(假设两个表结构一样)
INSERT INTO 新表
SELECT * FROM 旧表

4.复制旧表的数据到新表(假设两个表结构不一样)
INSERT INTO 新表(字段1,字段2,…….)
SELECT 字段1,字段2,…… FROM 旧表

SQLite性能优化

主要通过pragma指令来实现。

比如: 空间释放、磁盘同步、Cache大小等。

不要打开。前文提高了,Vacuum的效率非常低!

PRAGMA auto_vacuum;
PRAGMA auto_vacuum = 0 | 1;

查询或设置数据库的auto-vacuum标记。

正常情况下,当提交一个从数据库中删除数据的事务时,数据库文件不改变大小。未使用的文件页被标记并在以后的添加操作中 再次使用。这种情况下使用VACUUM命令释放删除得到的空间。

当开启auto-vacuum,当提交一个从数据库中删除数据的事务时,数据库文件自动收缩, (VACUUM命令在auto-vacuum开启的数据库中不起作用)。数据库会在内部存储一些信息以便支持这一功能,这使得 数据库文件比不开启该选项时稍微大一些。

只有在数据库中未建任何表时才能改变auto-vacuum标记。试图在已有表的情况下修改不会导致报错。
建议改为8000

PRAGMA cache_size;
PRAGMA cache_size = Number-of-pages;

查询或修改SQLite一次存储在内存中的数据库文件页数。每页使用约1.5K内存,缺省的缓存大小是2000. 若需要使用改变大量多行的UPDATE或DELETE命令,并且不介意SQLite使用更多的内存的话,可以增大缓存以提高性能。

当使用cache_size pragma改变缓存大小时,改变仅对当前对话有效,当数据库关闭重新打开时缓存大小恢复到缺省大小。 要想永久改变缓存大小,使用default_cache_size pragma.
打开。不然搜索中文字串会出错。

PRAGMA case_sensitive_like;
PRAGMA case_sensitive_like = 0 | 1;

LIKE运算符的缺省行为是忽略latin1字符的大小写。因此在缺省情况下’a’ LIKE ‘A’的值为真。可以通过打开 case_sensitive_like pragma来改变这一缺省行为。当启用case_sensitive_like,’a’ LIKE ‘A’为假而 ‘a’ LIKE ‘a’依然为真。
打开。便于调试

PRAGMA count_changes;
PRAGMA count_changes = 0 | 1;

查询或更改count-changes标记。正常情况下INSERT, UPDATE和DELETE语句不返回数据。 当开启count-changes,以上语句返回一行含一个整数值的数据——该语句插入,修改或删除的行数。 返回的行数不包括由触发器产生的插入,修改或删除等改变的行数。

PRAGMA page_size;
PRAGMA page_size = bytes;

查询或设置page-size值。只有在未创建数据库时才能设置page-size。页面大小必须是2的整数倍且大于等于512小于等于8192。 上限可以通过在编译时修改宏定义SQLITE_MAX_PAGE_SIZE的值来改变。上限的上限是32768.
如果有定期备份的机制,而且少量数据丢失可接受,用OFF

PRAGMA synchronous;
PRAGMA synchronous = FULL; (2)
PRAGMA synchronous = NORMAL; (1)
PRAGMA synchronous = OFF; (0)

查询或更改”synchronous”标记的设定。第一种形式(查询)返回整数值。 当synchronous设置为FULL (2), SQLite数据库引擎在紧急时刻会暂停以确定数据已经写入磁盘。 这使系统崩溃或电源出问题时能确保数据库在重起后不会损坏。FULL synchronous很安全但很慢。 当synchronous设置为NORMAL, SQLite数据库引擎在大部分紧急时刻会暂停,但不像FULL模式下那么频繁。 NORMAL模式下有很小的几率(但不是不存在)发生电源故障导致数据库损坏的情况。但实际上,在这种情况 下很可能你的硬盘已经不能使用,或者发生了其他的不可恢复的硬件错误。 设置为synchronous OFF (0)时,SQLite在传递数据给系统以后直接继续而不暂停。若运行SQLite的应用程序崩溃, 数据不会损伤,但在系统崩溃或写入数据时意外断电的情况下数据库可能会损坏。另一方面,在synchronous OFF时 一些操作可能会快50倍甚至更多。

在SQLite 2中,缺省值为NORMAL.而在3中修改为FULL.

使用2,内存模式。

PRAGMA temp_store;
PRAGMA temp_store = DEFAULT; (0)
PRAGMA temp_store = FILE; (1)
PRAGMA temp_store = MEMORY; (2)

查询或更改”temp_store”参数的设置。当temp_store设置为DEFAULT (0),使用编译时的C预处理宏 TEMP_STORE来定义储存临时表和临时索引的位置。当设置为MEMORY (2)临时表和索引存放于内存中。 当设置为FILE (1)则存放于文件中。temp_store_directorypragma 可用于指定存放该文件的目录。当改变temp_store设置,所有已存在的临时表,索引,触发器及视图将被立即删除。

SQLite支持的编译指令(pragma)

SQLite支持的编译指令(pragma)

PRAGMA命令是用于修改SQlite库或查询SQLite库内部数据(non-table)的特殊命令。PRAGMA 命令使用与其它SQLite命令(e.g. SELECT, INSERT)相同的接口,但在如下重要方面与其它命令不同:

* 在未来的SQLite版本中部分pragma可能被删除或添加,小心使用。
* 当使用未知的pragma语句时不产生报错。未知的pragma仅仅会被忽略,即是说若是打错了pragma语句SQLite不会提示用户。
* 一些pragma在SQL编译阶段生效而非执行阶段。即是说若使用C语言的sqlite3_compile(), sqlite3_step(), sqlite3_finalize() API (或类似的封装接口中),pragma可能在调用sqlite3_compile()期间起作用。
* pragma命令不与其它SQL引擎兼容。

可用的pragma命令有如下四个基本类型:

* 用于察看当前数据库的模式。
* 用于修改SQLite库的操作或查询当前的操作模式。
* 用于查询或修改两个数据库的版本号,schema-version和user-version.
* 用于调试库和校验数据库文件。


PRAGMA命令语法

 

sql-statement ::= PRAGMA name [value] |
PRAGMA 
function(arg)

 

使用整数值value的pragma也可以使用符号表示,字符串”on“, “true“,和 “yes” 等同于1,”off“, “false“,和 “no“等同于0. 这些字符串大小写不敏感且无须进行引用。无法识别的字符串被当作1且不会报错。value返回时是整数。


用于修改SQLite库的操作的Pragma

  • PRAGMA auto_vacuum;
    PRAGMA auto_vacuum = 
    0 | 1;

    查询或设置数据库的auto-vacuum标记。

    正常情况下,当提交一个从数据库中删除数据的事务时,数据库文件不改变大小。未使用的文件页被标记并在以后的添加操作中 再次使用。这种情况下使用VACUUM命令释放删除得到的空间。

    当开启auto-vacuum,当提交一个从数据库中删除数据的事务时,数据库文件自动收缩, (VACUUM命令在auto-vacuum开启的数据库中不起作用)。数据库会在内部存储一些信息以便支持这一功能,这使得 数据库文件比不开启该选项时稍微大一些。

    只有在数据库中未建任何表时才能改变auto-vacuum标记。试图在已有表的情况下修改不会导致报错。

  • PRAGMA cache_size;
    PRAGMA cache_size = 
    Number-of-pages;

    查询或修改SQLite一次存储在内存中的数据库文件页数。每页使用约1.5K内存,缺省的缓存大小是2000. 若需要使用改变大量多行的UPDATE或DELETE命令,并且不介意SQLite使用更多的内存的话,可以增大缓存以提高性能。

    当使用cache_size pragma改变缓存大小时,改变仅对当前对话有效,当数据库关闭重新打开时缓存大小恢复到缺省大小。 要想永久改变缓存大小,使用default_cache_size pragma.

  • PRAGMA case_sensitive_like;
    PRAGMA case_sensitive_like = 
    0 | 1;

    LIKE运算符的缺省行为是忽略latin1字符的大小写。因此在缺省情况下‘a’ LIKE ‘A’的值为真。可以通过打开 case_sensitive_like pragma来改变这一缺省行为。当启用case_sensitive_like,‘a’ LIKE ‘A’为假而 ‘a’ LIKE ‘a’依然为真。

  • PRAGMA count_changes;
    PRAGMA count_changes = 
    0 | 1;

    查询或更改count-changes标记。正常情况下INSERT, UPDATE和DELETE语句不返回数据。 当开启count-changes,以上语句返回一行含一个整数值的数据——该语句插入,修改或删除的行数。 返回的行数不包括由触发器产生的插入,修改或删除等改变的行数。

  • PRAGMA default_cache_size;
    PRAGMA default_cache_size = 
    Number-of-pages;

    查询或修改SQLite一次存储在内存中的数据库文件页数。每页使用约1.5K内存,它与 cache_sizepragma类似,只是它永久性地改变缓存大小。 利用该pragma,你可以设定一次缓存大小,并且每次重新打开数据库时都继续使用该值。

  • PRAGMA default_synchronous;

    该语句在2.8版本中可用,但在3.0版中被去掉了。这条pragma很危险且不推荐使用,安全起见在该文档中不涉及此pragma的用法。

  • PRAGMA empty_result_callbacks;
    PRAGMA empty_result_callbacks = 
    0 | 1;

    查询或更改empty-result-callbacks标记。

    empty-result-callbacks标记仅仅影响sqlite3_exec API函数。正常情况下,empty-result-callbacks标记清空, 则对返回0行数据的命令不调用sqlite3_exec()的回叫函数,当设置了empty-result-callbacks,则调用回叫 函数一次,置第三个参数为0 (NULL).这使得使用sqlite3_exec() API的程序即使在一条查询不返回数据时依然检索字段名。

  • PRAGMA encoding;
    PRAGMA encoding = “UTF-8”;
    PRAGMA encoding = “UTF-16”;
    PRAGMA encoding = “UTF-16le”;
    PRAGMA encoding = “UTF-16be”;

    在第一种形式中,若主数据库已创建,这条pragma返回主数据库使用得文本编码格式,为 “UTF-8”, “UTF-16le” (little-endian UTF-16 encoding) 或者”UTF-16be” (big-endian UTF-16 encoding)中的一种。 若主数据库未创建,返回值为当前会话创建的主数据库将要使用的文本编码格式。

    第二种及以后几种形式只在主数据库未创建时有效。这时该pragma设置当前会话创建的主数据库将要使用的文本编码格式。 “UTF-16″表示”使用本机字节顺序的UTF-16编码”。若这些形式在主数据库创建后使用,将被忽略且不产生任何效果。

    数据库的编码格式设置后不能够被改变。

    ATTACH命令创建的数据库使用与主数据库相同的编码格式。

  • PRAGMA full_column_names;
    PRAGMA full_column_names = 
    0 | 1;

    查询或更改the full-column-names标记。该标记影响SQLite命名SELECT语句(当字段表达式为表-字段或通配符”*”时) 返回的字段名的方式。正常情况下,当SELECT语句将两个或多个表连接时, 这类结果字段的返回名为,当SELECT语句查询一个单独的表时, 返回字段名为。当设置了full-column-names标记,返回的字段名将统一为 不管是否对表进行了连接。

    若short-column-names和full-column-names标记同时被设置,则使用full-column-names方式。

  • PRAGMA fullfsync
    PRAGMA fullfsync = 
    0 | 1;

    查询或更改fullfsync标记。该标记决定是否在支持的系统上使用F_FULLFSYNC同步模式。缺省值为off.截至目前(2006-02-10) 只有Mac OS X 系统支持F_FULLFSYNC.

  • PRAGMA page_size;
    PRAGMA page_size = 
    bytes;

    查询或设置page-size值。只有在未创建数据库时才能设置page-size。页面大小必须是2的整数倍且大于等于512小于等于8192。 上限可以通过在编译时修改宏定义SQLITE_MAX_PAGE_SIZE的值来改变。上限的上限是32768.

  • PRAGMA read_uncommitted;
    PRAGMA read_uncommitted = 
    0 | 1;

    查询,设置或清除READ UNCOMMITTED isolation(读取未授权的分隔符).缺省的SQLite分隔符等级是SERIALIZABLE. 任何线程或进程可选用READ UNCOMMITTED isolation,但除了共享公共页和schema缓存的连接之间以外的地方也会 使用SERIALIZABLE.缓存共享通过 sqlite3_enable_shared_cache() API开启,且只在运行同一线程的连接间有效。缺省情况下缓存共享是关闭的。

  • PRAGMA short_column_names;
    PRAGMA short_column_names = 
    0 | 1;

    查询或更改the short-column-names标记。该标记影响SQLite命名SELECT语句(当字段表达式为表-字段或通配符”*”时) 返回的字段名的方式。正常情况下,当SELECT语句将两个或多个表连接时, 这类结果字段的返回名为,当SELECT语句查询一个单独的表时, 返回字段名为。当设置了full-column-names标记,返回的字段名将统一为 不管是否对表进行了连接。

    若short-column-names和full-column-names标记同时被设置,则使用full-column-names方式。

  • PRAGMA synchronous;
    PRAGMA synchronous = FULL; 
    (2)
    PRAGMA synchronous = NORMAL; 
    (1)
    PRAGMA synchronous = OFF; 
    (0)

    查询或更改”synchronous”标记的设定。第一种形式(查询)返回整数值。 当synchronous设置为FULL (2), SQLite数据库引擎在紧急时刻会暂停以确定数据已经写入磁盘。 这使系统崩溃或电源出问题时能确保数据库在重起后不会损坏。FULL synchronous很安全但很慢。 当synchronous设置为NORMAL, SQLite数据库引擎在大部分紧急时刻会暂停,但不像FULL模式下那么频繁。 NORMAL模式下有很小的几率(但不是不存在)发生电源故障导致数据库损坏的情况。但实际上,在这种情况 下很可能你的硬盘已经不能使用,或者发生了其他的不可恢复的硬件错误。 设置为synchronous OFF (0)时,SQLite在传递数据给系统以后直接继续而不暂停。若运行SQLite的应用程序崩溃, 数据不会损伤,但在系统崩溃或写入数据时意外断电的情况下数据库可能会损坏。另一方面,在synchronous OFF时 一些操作可能会快50倍甚至更多。

    在SQLite 2中,缺省值为NORMAL.而在3中修改为FULL.

  • PRAGMA temp_store;
    PRAGMA temp_store = DEFAULT;
     (0)
    PRAGMA temp_store = FILE;
     (1)
    PRAGMA temp_store = MEMORY;
     (2)

    查询或更改”temp_store“参数的设置。当temp_store设置为DEFAULT (0),使用编译时的C预处理宏 TEMP_STORE来定义储存临时表和临时索引的位置。当设置为MEMORY (2)临时表和索引存放于内存中。 当设置为FILE (1)则存放于文件中。temp_store_directory pragma 可用于指定存放该文件的目录。当改变temp_store设置,所有已存在的临时表,索引,触发器及视图将被立即删除。

    库中的编译时C预处理标志TEMP_STORE可以覆盖该pragma设置。下面的表给出TEMP_STORE预处理宏和 temp_store pragma交互作用的总结:

    TEMP_STORE PRAGMA
    temp_store
    临时表和索引
    使用的存储方式
    0 any 文件
    1 0 文件
    1 1 文件
    1 2 内存
    2 0 内存
    2 1 文件
    2 2 内存
    3 any 内存

  • PRAGMA temp_store_directory;
    PRAGMA temp_store_directory = ‘directory-name’;

    查询或更改”temp_store_directory”设置——存储临时表和索引的文件所在的目录。 仅在当前连接有效,在建立新连接时重置为缺省值。

    当改变了temp_store_directory设置,所有已有的临时表,索引,触发器,视图会被直接删除。 建议在数据库一打开时就设置好temp_store_directory.

    directory-name需用单引号引起来。要想恢复缺省目录,把directory-name设为空字符串。例如 PRAGMA temp_store_directory = ”.若directory-name未找到或不可写会引发错误。

    临时文件的缺省目录与主机的系统有关,使用Unix/Linux/OSX系统的主机,缺省目录是如下序列之中第一个可写的 /var/tmp, /usr/tmp, /tmp,current-directory.对于Windows NT,缺省目录由Windows决定,一般为C:\Documents and Settings\user-name\Local Settings\Temp\. SQLite创建的临时文件在使用完毕时就被unlink,所以操作系统可以在SQLite进程进行中自动删除临时文件。 于是,正常情况下不能通过ls 或 dir命令看到临时文件。


用于查询数据库的schema的Pragma

  • PRAGMA database_list;

    对每个打开的数据库,使用该数据库的信息调用一次回叫函数。使用包括附加的数据库名和索引名在内的参数。第一行用于主数据库,第二行用于存放临时表的临时数据库。

  • PRAGMA foreign_key_list(table-name);

    对于参数表中每个涉及到字段的外键,使用该外键的信息调用一次回叫函数。每个外键中的每个字段都将调用一次回叫函数。

  • PRAGMA index_info(index-name);

    对该索引涉及到的每个字段,使用字段信息(字段名,字段号)调用一次回叫函数。

  • PRAGMA index_list(table-name);

    对表中的每个索引,使用索引信息调用回叫函数。参数包括索引名和一个指示索引是否唯一的标志。

  • PRAGMA table_info(table-name);

    对于表中的每个字段,使用字段信息(字段名,数据类型,可否为空,缺省值)调用回叫函数。


用于查询/更改版本信息的Pragma

  • PRAGMA [database.]schema_version;
    PRAGMA [database.]schema_version = 
    integer ;
    PRAGMA [database.]user_version;
    PRAGMA [database.]user_version = 
    integer ;

    这两条pragma分别用于设置schema-version和user-version的值。schema-version 和user-version均为32位有符号整数,存放于数据库头中。

    schema-version通常只由SQLite内部操作。每当数据库的schema改变时(创建或撤消表或索引),SQLite 将这个值增大。schema版本在每一次query被执行时被SQLite所使用,以确定编译SQL query时内部cache的schema与编译后的query实际执行时数据库的schema相匹配。使用”PRAGMA schema_version”更改schema-version会破坏这一机制,有导致程序崩溃或数据库损坏的潜在危险。请小心使用!

    user-version不在SQLite内部使用,任何程序可以用它来做任何事。


用于库debug的Pragma

  • PRAGMA integrity_check;

    该命令对整个数据库进行完整性检查,查找次序颠倒的记录,丢失的页,残缺的记录以及损坏的索引。若发现任何问题则返回一形容问题所在的字符串,若一切正常返回”ok”.

  • PRAGMA parser_trace = ON; (1)
    PRAGMA parser_trace = OFF;
     (0)

    打开或关闭SQLite库中的SQL语法分析追踪,用于debug.只有当SQLite不使用NDEBUG宏进行编译时该pragma才可用。

  • PRAGMA vdbe_trace = ON; (1)
    PRAGMA vdbe_trace = OFF;
     (0)

    打开或关闭SQLite库中的虚拟数据库引擎追踪,用于debug.更多信息,察看 VDBE文档。

  • PRAGMA vdbe_listing = ON; (1)
    PRAGMA vdbe_listing = OFF;
     (0)

    打开或关闭虚拟机程序列表,当开启列表功能,整个程序的内容在执行前被打印出来,就像在每条语句之前自动执行EXPLAIN. 语句在打印列表之后正常执行。用于debug.更多信息,察看 VDBE文档。

MYSQL与SQLITE重置AUTO_INCREMENT初始值

MYSQL重置AUTO_INCREMENT初始值的方法很简单
可就是SQLITE的重置方法在国内还极少人有记载(至少本人找了很久没找到)
于是到美国漫游了一下,终于功夫不负有心人……

SQLITE AUTO_INCREMENT 复位:

DELETE FROM sqlite_sequence WHERE name = 'your_table_name'

MYSQL AUTO_INCREMENT 复位:

ALTER TABLE your_table_name AUTO_INCREMENT = 1

SQLite数据库是中小站点CMS的最佳选择

SQLite 是一个类似Access的轻量级数据库系统,但是更小、更快、容量更大,并发更高。为什么说 SQLite 最适合做 CMS (内容管理系统)呢?并不是说其他数据库不好, Oracle、MySQL、SQLServer 也都是非常优秀的 DBS,只不过他们设计目标不同,特性不同,所以只有更适用某个应用场景,没有绝对的好坏之分。
我归纳的中小型站点的CMS的特点如下:
1、数据量不超过10万
2、日页面访问量不超过10万
3、 一部分网站全部生成静态页面,一部分网站实时查询数据库动态访问
4、 站长不懂技术,不懂得复杂的数据库维护,只会用 FTP 管理网站
5 、个人站点基本上是一个人管理,一般情况下只有一个人在访问后台,没有并发
6、 对数据库来说是读多写少,只有在站长访问后台的时候才会写入
7、 多运行于虚拟主机,大部分PHP主机均同时支持MySQL,小部分PHP主机需要单独购买MySQL,PHP+MySQL的主机价格较PHP主机价格高。 (以万网为例:最便宜的PHP空间780元,最便宜的PHP+MySQL的PHP空间1150元)
8、 多数中小站点的HTTP服务与MySQL部署在同一服务器上
SQLite 的优点在中小网站CMS应用场景下表现突出:
1、与MySQL相比,它更彻底的免费,并且没有任何使用上的限制
2、非常小巧,PHP5以上版本中无需任何配置即可支持SQLite
3、无需单独购买数据库服务,无服务器进程,配置成本为零
4、整个数据库存储在一个单个的文件中,数据导入导出备份恢复都是复制文件,维护难度为零
5、读速度快,在数据量不是很大的情况下速度较快,更重要的是:省掉了一次数据库远程链接没有复杂的权限验证,打开就能操作
SQLite的缺点在中小网站 CMS 应用场景下被规避:
1、并发低 动态访问时当访问量不超过10万PV的时候,SQLite 超过 Access 的并发能力已经绰绰有余;生成静态页后更无需考虑数据库的并发问题
2、在大数据量的情况下表现较差 但是中小站点一般情况下数据量不超过10万,而SQlite 在 100 万数据量之下表现还不错,因为省掉了对数据库服务器的远程连接甚至会更快
3、写入较慢 默认配置下的 SQlite 的写入速度比MySQL慢了很多,但是 CMS 应用场景的写入操作较少。在插入新文章的时候基本感受不到慢。集中的写数据库操作只有在安装的时候会出现,不过只出现一次,可以忽略
4、为已有的表加索引较慢 但是在中小站点CMS中不会有这样的需求,可以忽略
5、无法将 MySQL 部署到与前端机不同的服务器上,但是中小站点也没有分开部署的需求
综上所述:在中小站点 CMS 的应用场景下 SQLite 能最大限度的降低建站成本,降低维护难度,又很好得规避了自身的缺点。所以我认为未来支持 SQLite 的 CMS 系统一定会大行其道。