导出要用到MySQL的mysqldump工具,基本用法是:   复制代码 代码如下:shell> mysqldump [OPTIONS] database [tables]   如果你不给定任何表,整个数据库将被导出。   通过执行mysqldump --help,你能得到你mysqldump的版本支持的选项表。   注意,如果你运行mysqldump没有--quick或--opt选项,mysqldump将在导出结果前装载整个结果集到内存中,如果你正在导出一个大的数据库,这将可能是一个问题。   mysqldump支持下列选项:   复制代码 代码如下:--add-locks   在每个表导出之前增加LOCK TABLES并且之后UNLOCK TABLE。(为了使得更快地插入到MySQL)。   复制代码 代码如下:--add-drop-table   在每个create语句之前增加一个drop table。   复制代码 代码如下:--allow-keywords允许创建是关键词的列名字。这由表名前缀于每个列名做到。   复制代码 代码如下:-c, --complete-insert   使用完整的insert语句(用列名字)。   复制代码 代码如下:-C, --compress   如果客户和服务器均支持压缩,压缩两者间所有的信息。   复制代码 代码如下:--delayed   用INSERT DELAYED命令插入行。   复制代码 代码如下:-e, --extended-insert   使用全新多行INSERT语法。(给出更紧缩并且更快的插入语句)   复制代码 代码如下:-#, --debug[=option_string]   跟踪程序的使用(为了调试)。   复制代码 代码如下:--help   显示一条帮助消息并且退出。   复制代码 代码如下:--fields-terminated-by=...       --fields-enclosed-by=...       --fields-optionally-enclosed-by=...       --fields-escaped-by=...       --fields-terminated-by=...   这些选择与-T选择一起使用,并且有相应的LOAD DATA INFILE子句相同的含义。   LOAD DATA INFILE语法。   复制代码 代码如下:-F, --flush-logs   在开始导出前,洗掉在MySQL服务器中的日志文件。   复制代码 代码如下:-f, --force,   即使我们在一个表导出期间得到一个SQL错误,继续。   复制代码 代码如下:-h, --host=..   从命名的主机上的MySQL服务器导出数据。缺省主机是localhost。   复制代码 代码如下:-l, --lock-tables.   为开始导出锁定所有表。   复制代码 代码如下:-t, --no-create-info   不写入表创建信息(CREATE TABLE语句)   复制代码 代码如下:-d, --no-data   不写入表的任何行信息。如果你只想得到一个表的结构的导出,这是很有用的!   复制代码 代码如下:--opt   同复制代码 代码如下:--quick --add-drop-table --add-locks --extended-insert --lock-tables。   应该给你为读入一个MySQL服务器的尽可能最快的导出。   复制代码 代码如下:-pyour_pass, --password[=your_pass]   与服务器连接时使用的口令。如果你不指定“=your_pass”部分,mysqldump需要来自终端的口令。   复制代码 代码如下:-P port_num, --port=port_num   与一台主机连接时使用的TCP/IP端口号。(这用于连接到localhost以外的主机,因为它使用 Unix套接字。)   复制代码 代码如下:-q, --quick   不缓冲查询,直接导出至stdout;使用mysql_use_result()做它。   复制代码 代码如下:-S /path/to/socket, --socket=/path/to/socket   与localhost连接时(它是缺省主机)使用的套接字文件。   复制代码 代码如下:-T, --tab=path-to-some-directory   对 于每个给定的表,创建一个table_name.sql文件,它包含SQL CREATE 命令,和一个table_name.txt文件,它包含数 据。 注意:这只有在mysqldump运行在mysqld守护进程运行的同一台机器上的时候才工作。.txt文件的格式根据--fields-xxx和 --lines--xxx选项来定。   复制代码 代码如下:-u user_name, --user=user_name   与服务器连接时,MySQL使用的用户名。缺省值是你的Unix登录名。   复制代码 代码如下:-O var=option, --set-variable var=option设置一个变量的值。可能的变量被列在下面。   复制代码 代码如下:-v, --verbose   冗长模式。打印出程序所做的更多的信息。   复制代码 代码如下:-V, --version   打印版本信息并且退出。   复制代码 代码如下:-w, --where='where-condition'   只导出被选择了的记录;注意引号是强制的!   复制代码 代码如下:"--where=user='jimf'" "-wuserid>1" "-wuserid<1"  最常见的mysqldump使用可能制作整个数据库的一个备份:  复制代码 代码如下:mysqldump --opt database > backup-file.sql   但是它对用来自于一个数据库的信息充实另外一个MySQL数据库也是有用的:   复制代码 代码如下:mysqldump --opt database | mysql --host=remote-host -C database   由于mysqldump导出的是完整的SQL语句,所以用mysql客户程序很容易就能把数据导入了:   复制代码 代码如下:shell> mysqladmin create target_db_name   shell> mysql target_db_name < backup-file.sql  就是  复制代码 代码如下:shell> mysql 库名 < 文件名 几个常用用例:1.导出整个数据库复制代码 代码如下: mysqldump -u 用户名 -p 数据库名 > 导出的文件名     mysqldump -u wcnc -p smgp_apps_wcnc > wcnc.sql2.导出一个表 复制代码 代码如下:mysqldump -u 用户名 -p 数据库名 表名> 导出的文件名 mysqldump -u wcnc -p smgp_apps_wcnc users> wcnc_users.sql3.导出一个数据库结构  复制代码 代码如下:mysqldump -u wcnc -p -d --add-drop-table smgp_apps_wcnc >d:wcnc_db.sql -d 没有数据 --add-drop-table 在每个create语句之前增加一个drop table 4.导入数据库  常用source 命令  进入mysql数据库控制台,  如复制代码 代码如下:mysql -u root -p     mysql>use 数据库  然后使用source命令,后面参数为脚本文件(如这里用到的.sql)复制代码 代码如下:  mysql>source d:wcnc_db.sqlmysql使用source命令导入数据库编码问题mysql>use 数据库名称(与你的网站数据库名相同)复制代码 代码如下:set names utf8; (先确认编码 注意不是UTF-8)复制代码 代码如下:source D:

前言上一篇《浅析SQL Server 聚焦索引对非聚集索引的影响》我们讲了聚集索引对非聚集索引的影响,对数据库一直在强调的性能优化,所以这一节我们统筹讲讲利用索引来看看查询执行计划是怎样的,简短的内容,深入的理解。透过索引来看查询执行计划我们首先来看看第一个例子1、默认使用索引USE TSQL2012GOSELECT orderid FROM Sales.OrdersSELECT * FROM Sales.Orders上述我们看到第2个查询的所需要的开销是第1个查询开销的3倍,当然其中也涉及到第1个查询只是返回一列而第2个查询返回所有列,这其中也耗费一小部分性能。对于SQL Server查询而言,它内部会利用索引来走最短的路径获取最优的性能。我们能够注意到即使将orderid作为主键,但是返回数据并不是采用的主键所自动生成的聚集索引而是非聚集索引。相信有很多人主观上觉得返回主键而且查询没有查询条件应该是走主键的聚集索引,但是有时候事实并非如此,上一篇我们已经讨论过这个问题,不再叙述。在第2个查询中利用*返回数据则是利用主键的聚集索引。2、强制主键使用聚集索引强制使用索引我们利用With(index(索引名称))来创建,如下:USE TSQL2012GOSELECT orderid FROM Sales.Orders WITH(INDEX(PK_Orders))SELECT * FROM Sales.Orders WITH(INDEX(PK_Orders))我们从上可以看出默认返回主键列时利用非聚集索引,这里我们强制让它走聚集索引,而对于第2个查询就不用说了,此时二者的开销是相当的。3、强制使用非聚集索引我们继续往下看,对查询强制使用非聚集索引查找,如下:USE TSQL2012GOSELECT orderid FROM Sales.Orders WITH(INDEX(idx_nc_custid))SELECT * FROM Sales.Orders WITH(INDEX(idx_nc_custid))由上可见,二者开销区别之大,对于使用非聚集索引查询1返回单列,而查询2返回所有列的速度快如此之多,通过以上默认使用索引、强制使用聚集索引、强制使用非聚集索引我们知道对于对于检索所有列结果集使用主键的聚集索引是最佳选择。总结 通过上述演示我们知道即使创建了聚集索引也不会利用聚集索引检索结果,有时候使用非聚集索引比使用聚集索引会提供更好的性能,当然不能一概而论,二者皆有使用场景。当每一次面试时谈到数据库优化时,第一想到的是索引,然后就没有下文了,如何使用索引,怎么在不同场景使用不同的索引呢?在任何数据库中索引一直都是一个很大的话题且是一个复杂的内容,复杂的内容皆是由简单堆积而成,我们必须如蜗牛般去慢慢研究,抽茧剥丝,最终才会有一个好的效果。简短的内容,深入的理解。以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,同时也希望多多支持脚本之家!

凭经验,这是索引碎片问题。检查索引碎片DBCC SHOWCONTIG(表),得到如下结果: DBCC SHOWCONTIG 正在扫描 'A' 表... 表: 'A'(884198200);索引 ID: 1,数据库 ID: 13 已执行 TABLE 级别的扫描。 - 扫描页数.....................................: 3127 - 扫描扩展盘区数...............................: 403 - 扩展盘区开关数...............................: 1615 - 每个扩展盘区上的平均页数.....................: 7.8 - 扫描密度[最佳值:实际值]....................: 24.20%[391:1616] - 逻辑扫描碎片.................................: 68.02% - 扩展盘区扫描碎片.............................: 38.46% - 每页上的平均可用字节数.......................: 2073.2 - 平均页密度(完整)...........................: 74.39% DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。 由上我们看出,逻辑扫描碎片和扩展盘区扫描碎片都非常大,果真需要对索引碎片进行处理了。 一般有两种方法解决,一是利用DBCC INDEXDEFRAG整理索引碎片,二是利用DBCC DBREINDEX重建索引。二者各有优缺点。调用微软的原话如下: DBCC INDEXDEFRAG 命令是联机操作,所以索引只有在该命令正在运行时才可用。而且可以在不丢失已完成工作的情况下中断该操作。这种方法的缺点是在重新组织数据方面没有聚集索引的除去/重新创建操作有效。 重新创建聚集索引将对数据进行重新组织,其结果是使数据页填满。填满程度可以使用 FILLFACTOR 选项进行配置。这种方法的缺点是索引在除去/重新创建周期内为脱机状态,并且操作属原子级。如果中断索引创建,则不会重新创建该索引。 也就是说,要想获得好的效果,还是得用重建索引,所以决定重建索引。 DBCC DBREINDEX(表,索引名,填充因子) 第一个参数,可以是表名,也可以是表ID。 第二个参数,如果是'',表示影响该表的所有索引。 第三个参数,填充因子,即索引页的数据填充程度。如果是100,表示每一个索引页都全部填满,此时select效率最高,但以后要插入索引时,就得移动后面的所有页,效率很低。如果是0,表示使用先前的填充因子值。 DBCC DBREINDEX(A,'',100) 重新测试查询速度,飞快。

有台linux服务器,系统为centos系统. 网站突然连接不上数据库,于是朋友直接重启了一下服务器。进到cli模式下,执行 service myqsld start 发现还是提示"mysql deamon failed to start"错误信息. # /etc/init.d/mysqld start MySQL Daemon failed to start. Starting mysqld: [FAILED] 查看mysqld的log文件 #less /var/log/mysqld.log /usr/libexec/mysqld: Can't change dir to ‘XXX' (Errcode: 13) 首先是查看数据库日志 mysqld started [Warning] Can't create test file xxx.lower-test [Warning] Can't create test file xxx.lower-test /usr/libexec/mysqld: Can't change dir to '/xxx' (Errcode: 13) [ERROR] Aborting 首先检查数据目录和日志目录的权限和所属用户,权限和所属用户都没问题,那应该是SELINUX的权限限制了。 先查看当前配置信息. # getenforce Enforcing 就表明SELinux已经启用.只需要关闭即可。 关闭方法:

突然收到MySQL报警,从库的数据库挂了,一直在不停的重启,打开错误日志,发现有张表坏了。innodb表损坏不能通过repair table 等修复myisam的命令操作。现在记录下解决过程,下次遇到就不会这么手忙脚乱了。处理过程: 一遇到报警之后,直接打开错误日志,里面的信息:InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.130509 20:33:48 InnoDB: Page dump in ascii and hex (16384 bytes):##很多十六进制的代码…………InnoDB: End of page dump130509 20:37:34 InnoDB: Page checksum 1958578898, prior-to-4.0.14-form checksum 3765017239InnoDB: stored checksum 3904709694, prior-to-4.0.14-form stored checksum 3765017239InnoDB: Page lsn 5 614270220, low 4 bytes of lsn at page end 614270220InnoDB: Page number (if stored to page already) 30506,InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 19InnoDB: Page may be an index page where index id is 54InnoDB: (index "PRIMARY" of table "maitem"."email_status")InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.InnoDB: It is also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: and rebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB: you can also try to fix the corruptionInnoDB: by dumping, dropping, and reimportingInnoDB: the corrupt table. You can use CHECKInnoDB: TABLE to scan your table for corruption.InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.InnoDB: A new raw disk partition was initialized orInnoDB: innodb_force_recovery is on: we do not allowInnoDB: database modifications by the user. Shut downInnoDB: mysqld and edit my.cnf so that newraw is replacedInnoDB: with raw, and innodb_force_... is removed.130509 20:39:35 [Warning] Invalid (old?) table or database name '#sql2-19c4-5'从错误日志里面很清楚的知道哪里出现了问题,该怎么处理。这时候数据库隔几s就重启,所以差不多可以说你是访问不了数据库的。所以马上想到要修复innodb表了。以前在Performance的blog上看过类似文章。当时想到的是在修复之前保证数据库正常,不是这么异常的无休止的重启。所以就修改了配置文件的一个参数:innodb_force_recoveryinnodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0,表示当需要恢复时执行所有的innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。因为错误日志里面提示出现了坏页,导致数据库崩溃,所以这里把innodb_force_recovery 设置为1,忽略检查到的坏页。重启数据库之后,正常了,没有出现上面的错误信息。找到错误信息出现的表:(index "PRIMARY" of table "maitem"."email_status")数据页面的主键索引(clustered key index)被损坏。这种情况和数据的二级索引(secondary indexes)被损坏相比要糟很多,因为后者可以通过使用OPTIMIZE TABLE命令来修复,但这和更难以恢复的表格目录(table dictionary)被破坏的情况来说要好一些。操作步骤:因为被破坏的地方只在索引的部分,所以当使用innodb_force_recovery = 1运行InnoDB时,操作如下:执行check,repair table 都无效alter table email_status engine =myisam; #也报错了,因为模式是innodb_force_recovery =1。ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)建立一张表:create table email_status_bak #和原表结构一样,只是把INNODB改成了MYISAM。把数据导进去insert into email_status_bak select * from email_status;删除掉原表:drop table email_status;注释掉innodb_force_recovery 之后,重启。重命名:rename table edm_email_status_bak to email_status;最后该回存储引擎alter table edm_email_status engine = innodb总结:这里的一个重要知识点就是 对 innodb_force_recovery 参数的理解了,要是遇到数据损坏甚至是其他的损坏。可能上面的方法不行了,需要尝试另一个方法:insert into tb select * from ta limit X;甚至是dump出去,再load回来。

分类:365bet娱乐城官网

时间:2016-02-06 07:31:02