access数据库sql语句大全-access执行sql语句

【树萌致力于成为最优秀的数据科学社区，专注于大数据、分析挖掘、数据可视化。 业务范围：线下活动、线上课程、猎头服务、项目对接】

原作者：黄山（mchdba）|来自：ITPUB技术社区

一、mysql架构

由数据库和数据库实例组成，是单入口多线程架构。

数据库：物理操作系统文件或其他文件的集合。 在mysql中，数据库文件可以是frm、myd、myi、ibd等结尾的文件，在使用ndb存储引擎时，不是os文件，而是存储在内存中的文件。

数据库实例：由数据库后台进程/线程和一块共享内存区组成，可以被正在运行的后台进程/线程共享。

2、mysql文件类型

Mysql的主要文件类型有以下几种：

参数文件：在哪里可以找到mysql实例启动时的数据库文件，并指定一些初始化参数，其中定义了某个内存结构的大小等设置，还介绍了参数类型和定义范围。

日志文件：记录mysql响应某个条件时写入的文件。

套接字文件：用linux的mysql命令行窗口登录时需要的文件。

Pid文件：mysql实例的进程文件。

mysql表结构文件：存放mysql表结构定义文件。

存储引擎文件：记录存储引擎信息的文件。

3.参数文件my.cnf

Mysql实例启动时，会先读取配置参数文件my.cnf

找到 my.cnf 位置

(1): 默认: mysql--help|grep my.cnf

(2)：后台进程查找：ps –eaf|grep mysql

(3)：全局搜索：find /-name my.cnf

可以使用vi直接维护修改里面的参数值

(1)动态：可以通过set实时修改

(2)static，只能在my.cnf中修改，需要重启才能生效

Mysql参数文件中的参数可以分为动态（dynamic）参数和静态（static）参数两种。 动态参数是指在mysql实例运行过程中可以修改，设置global sort_buffer_size=32999999； 修改后，其他连接会重新建立连接，才会生效。

有效范围分为：全局和会话。

静态指令在整个mysql实例运行过程中是不能修改的，就像read-only只读一样。

4.日志文件

日志文件记录影响 mysql 数据库的各种类型的活动。 常见的日志文件包括错误日志、二进制日志、慢查询日志、全量查询日志、重做日志和撤销日志。

5.错误日志

错误日志记录了mysql的启动、运行、关闭过程。 当mysql dba遇到问题时，他应该尽快查看这个错误日志文件。 这个文件不仅记录了错误信息，还记录了一些警告信息和纠正信息。 ，这个错误日志文件类似于oracle的alert文件，只是默认以error结尾。 您可以传递显示变量access数据库sql语句大全，例如“log_error”；

您可以看到带有服务器主机名文件名的错误文件。 当然你也可以在my.cnf中设置错误日志文件的路径：

vim my.cnf

日志错误=/usr/local/mysql/mysqld.log

我们可以在错误日志文件中看到一些数据库的启动信息、警告信息、错误信息

6.慢查询日志slow log

慢查询日志是记录运行缓慢的SQL语句信息，对SQL语句的优化有很好的帮助。 可以设置一个阈值，将运行时间超过阈值的SQL语句的运行信息记录到slow log日志里面去。 阈值可以通过long_query_time设置，也可以设置为毫秒和微秒：

但是需要注意一件事：运行时间等于阈值的，是不会被记录的。

另一个参数是 log_queries_not_using_indexes。 如果运行的SQL没有使用索引，只要超过阈值就会记录在慢查询日志中。

long_query_time=0（记录所有的sql可以审计），dba可以通过这个审计来促进业务的发展，可以知道哪些业务发展的好，哪些业务发展的不好，通过slow sql可以分析出哪些应用性能差，需要待优化 改进，dba最大的作用和贡献就是通过维护数据库来促进业务的发展和进步。 从数据到业务，这是我们需要一直努力的方向。

慢查询日志也可以记录在表中，

slow_log表，也可以把慢查询日志放到一个表中

显示像“log_output”这样的变量； 检查如果是文件，就存放在slowlog中，如果是表，就存放在slow_log表中。

7.全查询日志

它将所有的请求信息记录到mysql数据库中，不管请求信息是否被正确执行，默认文件名为hostname.log，可以看到request for access denied。

数据库审计+故障排除跟踪（3%-5%性能损失）

8.二进制日志

它记录了改变数据库的操作，但不包括select操作和show操作，因为这些操作并没有修改数据库本身。 如果还想记录select和show，需要查看之前的full query log。 另外binlog中还包括数据库变更操作的执行时间和执行时间等信息。

binary的主要功能如下：

(1)：还原恢复。 一些数据的恢复需要二进制日志。 整个数据库文件恢复后，可以在此基础上通过二进制日志进行点到时间的恢复。

(2)：复制。 其原理与恢复类似。 通过复制执行二进制日志，实现远程mysql数据库（slave）与mysql数据库（master）实时同步。

通过在my.cnf中设置log-bin=/home/data/mysql/binlog/mysql-bin.log来生效，默认在数据目录datadir下。

Binlog日志参数：

max_binlog_size：指定单个二进制文件的最大值。 如果超过这个值，会生成一个新的日志文件，后缀为+1，记录在.index文件中。 默认值是1G，但是从多年的dba生涯总结来看，64M是一个常见的大小设置。

binlog_cache_size:

使用innodb存储引擎时，所有未提交的二进制日志都会记录在一个缓存中，committed会在事务提交时直接将缓冲的二进制日志写入二进制日志文件，缓冲区的大小由binlog_cache_size决定决定这个buffer是基于session的，也就是每个线程需要事务的时候，mysql会分配一个binlog_cache_size的缓存，所以这个值的设置需要非常小心，不能设置太大，以免避免内存溢出。

同步二进制日志：

sync_binlog=N，引入了参数优化，大概意思是缓冲区每写N次，就同步到磁盘文件。 如果N设置为1，则每次都会写入binlog磁盘文件，最安全最安全，如果N>1，当发生意外时，意味着会有N-1个dml没有被写入binlog，可能会出现活跃数据不一致的情况。

binlog-do-db，binlog-ingore-db：

需要写入或忽略哪些库的日志。 默认为空，表示所有库的日志都可以写入二进制文件。

日志从属更新：

在slave server上开启slave log功能，让这台电脑可以组成一个镜像链（A->B->C），可以在slave库上生成二进制日志文件，在slave上挂载另一个slave图书馆图书馆。

binlog-format：日志格式

有语句，行，混合格式

声明：每条修改数据的sql都会记录在binlog中。

优点：无需记录每一行的变化，减少binlog日志量，节省IO，提高性能。 （与row相比，能节省多少性能和日志量取决于应用的SQL情况。通常情况下，以row格式修改或插入相同记录产生的日志量要比Statement产生的日志量小，但是考虑到如果条件更新操作，以及删除整表，alter table等操作，ROW格式会产生大量的日志，所以在考虑是否使用ROW格式日志时，应该根据应用的实际情况，产生的日志量会增加多少，以及由此带来的IO性能问题。）

缺点：由于只记录了执行语句，为了让这些语句在slave上正确运行，需要在每条语句执行时记录一些相关信息，以保证slave上可以获取到所有的语句并且在master端执行。 的结果。 另外，对于mysql的replication，像一些特定的函数，slave可以和master保持一致，也会有很多相关的问题（比如sleep()函数、last_insert_id()、用户自定义函数（udf ) 会有问题)。

2、Row：不记录sql语句上下文的相关信息，只保存哪条记录被修改了。

优点：binlog不需要记录执行的SQL语句的上下文相关信息，只需要记录记录被修改成什么。 所以rowlevel日志内容会清楚的记录每一行数据修改的细节。 并且不会出现某些特定情况下无法正确复制存储过程、函数或触发器调用和触发器的问题。

缺点：当所有执行的语句都记录在日志中时，会记录为每一行记录的修改，可能会产生大量的日志内容。 比如一条update语句修改了多条记录，那么binlog中的每一条修改都会被记录下来，这样就会造成大量的binlog日志，尤其是执行altertable等语句时，每条记录都会因为修改了表结构，则表的每条记录都会记录在日志中。

3.Mixedlevel：是以上两个层次的混合使用。 一般语句修改使用statment格式保存binlog。 比如一些功能，语句无法完成主从复制操作，采用行格式保存binlog。 MySQL会根据具体的sql语句来执行每一条，用于区分要记录的日志格式，即Statement和Row二选一。 新版MySQL Squadron的rowlevel模式也进行了优化，并不是所有的修改都会记录在rowlevel中，比如遇到表结构变化时，会记录在statement模式中。 对于update、delete等修改数据的语句，仍然会记录所有行的变化。

使用以下函数的语句也不能被复制：

*加载文件()

*UUID()

*用户（）

*FOUND_ROWS()

*SYSDATE()（除非在启动时启用了 --sysdate-is-now 选项）

同时，INSERT ... SELECT 会比 RBR 产生更多的行级锁

行，混合

9.socket套接字文件

linux系统下本地连接mysql可以使用linux域socketsocket方式，发送文件需要socket套接字，可以通过参数sockets控制。 一般默认在/tmp目录下，也可以通过以下两种方式查看：

1. ps -eaf|grep mysql |grep 套接字

[root@data01 binlog]# ps -eaf|grep mysql|grep socket

mysql 3152 1979 0 2 月 28 日？ 00:00:02 /usr/local/mysql/bin/mysqld--basedir=/usr/local/mysql--datadir=/home/data/mysql/data--plugin-dir=/usr/local/mysql/ lib/plugin --user=mysql --log-error=/usr/local/mysql/mysqld.log --open-files-limit=8192 --pid-file=/usr/local/mysql/mysqld.pid - -socket=/usr/local/mysql/mysql.sock --port=3306

[root@data01 binlog]#

2.

3.我的.cnf

套接字=/usr/local/mysql/mysql.sock

10.pid文件

当mysql实例启动时，它会将自己的进程id写入一个文件。 这个文件就是pid文件，由参数pid_file控制。 默认路径位于数据库目录中。 您可以通过以下三种方式查看：

1), 显示像'pid_file'这样的变量；

2)、ps -eaf|grepmysql|grep pid

3)、My.cnf(pid-file=/usr/local/mysql/mysqld.pid)

11.表结构文件

*.frm

*.ibd

12、innodb存储文件

innodb存储引擎在存储设计上模仿了oracle。 这个文件是默认的表空间文件，可以通过参数innodb_data_file_path来设置。 格式如下：

innodb_data_file_path= IBdata1:128M;IBdata2:128M:autoextend

多个文件可以组成一个表空间，文件的属性可以同时指定。 如果IBdata1和IBdata2位于不同的磁盘组，可以在一定程度上提高性能。 file后面的属性表示文件大小，autoextend表示还可以扩展。

但是如果innodb_file_per_table设置为true，那么表数据文件就会在一个单独的.ibd文件中，而不是在这个ibdata文件中。

13.重做文件

所有的数据库都是log first，先写log，再写数据文件，所以有redo log的规则。

默认情况下，将有两个文件名为 ib_logfile0 和 ib_logfile1。 在mysql数据库目录下可以看到这两个文件。 这对于 innodb 存储引擎非常重要，因为它们记录了 innodb 存储引擎的事务日志。

重做日志文件的主要用途是：在实例或介质发生故障时，重做日志可以派上用场。 如果数据库实例由于主机掉电而失效，InnoDB存储引擎会使用重做日志恢复到掉电前的时刻，以保证数据的完整性。

每个innodb存储引擎至少有一个重做日志组，每个组至少有2个重做日志文件，比如默认的ib_logfile0和ib_logfile1。 为了获得更高的可靠性，可以设置多个组，也可以设置每个组放在不同的磁盘上以提高性能

LSN 日志序列号：

增量生成的，可以唯一标记一个redo log，这对我们的数据库故障恢复非常重要。 可以唯一定位数据库运行状态。 至于具体怎么定位，可以去redo和undo的源码看看。 源代码：在“storage/innobase/include/log0log.h”

查看参数设置：show variables like 'innodb%log%'；

14.撤销日志

存在于共享表空间ibdata1中access数据库sql语句大全，有一个回滚段地址，存放头信息，配置头信息，段头信息，存放与redo相对的数据更新操作。 如果使用rollback，会将undo段中的数据写回数据文件。

如果使用单独的表空间，则直接存储在表的私有空间，而不是共享表空间。在innodb存储引擎中，undo log用于完成事务回滚和MVCC功能

重做和撤消不是相互独立的。 他们是相关的。 它们交替协作以确保数据的一致性和安全性。 具体可以参考何博士的文章。 关于redo和undo，参考何博士的资料：

何博士在数据库领域非常有权威。 他的文章都是干货，非常值得学习。 每个人都尝试花时间学习。

PS：资料收集自网络。 它是很久以前编译的。 我不记得来源了。 抱歉，如果重复相同的内容。