Linux中的sleep和select函数详解 (linux sleep select)
在Linux编程中，sleep和select是两个非常重要的函数，它们都涉及到时间和I/O操作。对于一个有效的Linux程序员而言，必须对这两个函数有一个深入的了解和掌握。本文将详细介绍关于sleep和select的概念，语法和应用。
1. sleep函数
sleep函数是Linux中一个非常常用的函数，在各种应用程序中都能看到它的身影。sleep函数的作用是让程序停止执行一段时间，通常是秒数的形式。在应用程序中，有些时候我们需要暂停一下程序的运行，让程序执行其他的操作。这时候，sleep函数就可以派上用场了。以下是sleep函数的语法：
“`c++
#include
unsigned int sleep(unsigned int seconds);
“`
其中，之一个参数表示程序执行暂停的时间，以秒为单位。在函数执行过程中，程序会进入休眠状态，对于除非紧急事件，否则程序不会任何用户输入或处理操作。
2. select函数
select函数是Linux中的又一重要函数。它的作用是对多个文件描述符进行等待，以判断是否有可读、写或异常事件发生。这个函数常常用于处理I/O操作，使程序能够同时处理多个文件操作。
以下是select函数的语法：
“`c++
#include
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
“`
参数说明：
– nfds：要被检查的文件描述符更大值，它通常设为需要检查的文件个数加一。
– readfds：用来监视是否有可以读取的数据，如果该参数为NULL，则不检查。
– writefds：用来监视是否有可以写入的数据，如果该参数为NULL，则不检查。
– exceptfds：用来监视异常情况，如果该参数为NULL，则不检查。
– timeout：select会阻塞timeout这个时间段，并等待这些文件描述符之中的事件发生。
select函数返回值表示事件发生的文件描述符数。
一般的，当在进行I/O操作时在想要同时处理多个文件描述符的话，select函数是非常常用的。我们可以选择把几个文件描述符储存于readfds、writefds、exceptfds，然后使用下面的步骤来进行文件描述符的监视：
“`c++
fd_set fdset;
FD_ZERO(&fdset);
FD_SET(sock,&fdset); // 假设 sock是需要监听的描述符
while(true) {
select(sock+1,&fdset,NULL,NULL,NULL); // select的超时参数暂设为NULL
if (FD_ISSET(sock,&fdset)) {
// sock有事件，处理代码
}
}
“`
在这个例子中， select函数在唯一的描述符sock上监听，并阻塞直到该socket产生了某个事件。然后我们就可以在该socket上进行数据的读取了。
相关问题拓展阅读：
怎么查找执行比较慢的sql语句
一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句 1，slow_query_log 这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。 2，long_query_time 当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。 3，slow_query_log_file 记录日志的文件名。 4，log_queries_not_using_indexes 这个参数设置为ON，可以捕获到所有未使用索引的SQL语句明山，尽管这个SQL语句有可能执行得挺快。 二、检测mysql中sql语句的效率的方法 1、通过查询日志 （1）、Windows下开启MySQL慢查询 MySQL在Windows系统中的配置文件一般是是my.ini找到下面加上 代码如下 log-slow-queries = F:/MySQL/log/mysqlslowquery。log long_query_time = 2 （2）、Linux下启用MySQL慢查询 MySQL在Windows系统中的厅槐谨配置文扮基件一般是是my.cnf找到下面加上 代码如下 log-slow-queries=/data/mysqldata/slowquery。log long_query_time=2 说明 log-slow-queries = F:/MySQL/log/mysqlslowquery。 为慢查询日志存放的位置，一般这个目录要有MySQL的运行帐号的可写权限，一般都将这个目录设置为MySQL的数据存放目录； long_query_time=2中的2表示查询超过两秒才记录；
一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句
1，slow_query_log
这个参数设置为ON，可以捕获执行时间超过一定数值的SQL语句。
2，long_query_time
当SQL语句执行时间超过此数值时，就会被记录到日志中，建议设置为1或者更短。
3，slow_query_log_file
记录日志的文件名。
4，log_queries_not_using_indexes
这个参数设置为ON，可以捕获到所有未使用索引的SQL语句，尽管这个SQL语句有可能执行得挺快。
二、检测mysql中sql语句的效率的方法
1、通过查询日志
（1）、Windows下开启MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.ini找到下面加上
代码如下
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
long_query_time = 2
（2）、Linux下启用MySQL慢查询
MySQL在Windows系统中的配置文件一般是是my.cnf找到下面加上
代码如下
log-slow-queries=/data/mysqldata/slowquery。log
long_query_time=2
说明
log-slow-queries = F:/MySQL/log/mysqlslowquery。
为慢查询日志存放的位置，一般这个目录要有MySQL的运行帐号的可写权限，一般都将这个目录设置为MySQL的数据存放目录；
long_query_time=2中的2表示查询超过两秒才记录；
2.show processlist 命令
SHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。
各列的含义和用途：
ID列
一个标识，你要kill一个语句的时候很有用，用命令杀掉此查询 /*/mysqladmin kill 进程号。
user列
显示单前用户，如果不是root，这个命令就只显示你权限范围内的sql语句。
host列
显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。
db列
显示这个进程目前连接的是哪个数据库。
command列
显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。
time列
此这个状态持续的时间，单位是秒。
state列
显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个 sql语句，以查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成
info列
显示这个sql语句，因为长度有限，所以长的sql语句就显示不全，但是一个判断问题语句的重要依据。
这个命令中最关键的李铅就是state列，mysql列出的状态主要有以下几种：
Checking table
正在检查数据表（这是自动的）。
Closing tables
正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。
Connect Out
复制从服务器正在连接主服务器。
Copying to tmp table on disk
由于临时结果集大于tmp_table_size，正在将临时表和唤从内存存储转为磁盘存储以此节省内存。
Creating tmp table
正在创建临时表以存放唤扰凯部分查询结果。
deleting from main table
服务器正在执行多表删除中的之一部分，刚删除之一个表。
deleting from reference tables
服务器正在执行多表删除中的第二部分，正在删除其他表的记录。
Flushing tables
正在执行FLUSH TABLES，等待其他线程关闭数据表。
Killed
发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效。
Locked
被其他查询锁住了。
Sending data
正在处理SELECT查询的记录，同时正在把结果发送给客户端。
Sorting for group
正在为GROUP BY做排序。
Sorting for order
正在为ORDER BY做排序。
Opening tables
这个过程应该会很快，除非受到其他因素的干扰。例如，在执ALTER TABLE或LOCK TABLE语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。
Removing duplicates
正在执行一个SELECT DISTINCT方式的查询，但是MySQL无法在前一个阶段优化掉那些重复的记录。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端。
Reopen table
获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。
Repair by sorting
修复指令正在排序以创建索引。
Repair with keycache
修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。
Searching rows for update
正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。
Sleeping
正在等待客户端发送新请求.
System lock
正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表，那么可以通过增加–skip-external-locking参数来禁止外部系统锁。
Upgrading lock
INSERT DELAYED正在尝试取得一个锁表以插入新记录。
Updating
正在搜索匹配的记录，并且修改它们。
User Lock
正在等待GET_LOCK()。
Waiting for tables
该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANAZE TABLE,或OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED已经处理完了所有待处理的插入操作，正在等待新的请求。
大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了，需要检查一下。
还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着。
例如如图：
3、explain来了解SQL执行的状态
explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。
使用方法，在select语句前加上explain就可以了：
例如：
explain select surname,first_name form a,b where a.id=b.id
结果如图
EXPLAIN列的解释
table
显示这一行的数据是关于哪张表的
type
这是重要的列，显示连接使用了何种类型。从更好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
possible_keys
显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key
实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句 中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len
使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数
rows
MYSQL认为必须检查的用来返回请求数据的行数
Extra
关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢
extra列返回的描述的意义
Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
Range checked for each Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
Using filesort
看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
Using temporary
看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
Where used
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）
const
表中的一个记录的更大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
eq_ref
在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
range
这个连接类型使用索引返回一个范围中的行，比如使用>或
index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
ALL
如何让epoll中断返回
如何让epoll中断返回？转自：
开发高性能网络程序时，windows开发者们言必称iocp，linux开发者们则言必称epoll。大家都明白epoll是一种IO多路复用技术，可以非常高效的处理数以百万计的socket句柄，比起以前的select和poll效率高大发了。我们用起epoll来都感觉挺爽，确实快，那么，它到底为什么可以高速处理这么多并发连接呢？
先简单回顾下如何使用C库封装的3个epoll系统调用吧。
1 int epoll_create(int size);
2 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
3 int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);
使用起来很清晰，首先要调用epoll_create建立一个epoll对象。参数size是内核保证能够正确处理的更大句柄数，多于这个更大数时内核可不保证效果。
epoll_ctl可以操作上面建立的epoll，例如，将刚建立的socket加入到epoll中让其监控，或者把 epoll正在监控的某个socket句柄移出epoll，不再监控它等等。
epoll_wait在调用时，在给定的timeout时间内，当在监控的所有句柄中有事件发生时，就返回用户态的进程。
从上面的调用方式就可以看到epoll比select/poll的优越之处：因为后者每次调用时都要传递你所要监控的所有socket给select/poll系统调用，这意味着需要将用户态的socket列表copy到内核态，如果以万计的句柄会导致每次都要copy几十几百KB的内存到内核态，非常低效。而我们调用epoll_wait时就相当于以往调用select/poll，但是这时却不用传递socket句柄给内核，因为内核已经在epoll_ctl中拿到了要监控的句柄列表。
所以，实际上在你调用epoll_create后，内核就已经在内核态开始准备帮你存储要监控的句柄了，每次调用epoll_ctl只是在往内核的数据结构里塞入新的socket句柄。
在内核里，一切皆文件。所以，epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统里创建一个file结点。当然这个file不是普通文件，它只服务于epoll。
epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

1 static int __init eventpoll_init(void)
2 {
… …
4
/* Allocates slab cache used to allocate “struct epitem” items */
epi_cache = kmem_cache_create(“eventpoll_epi”, sizeof(struct epitem),
0, SLAB_HWCACHE_ALIGN|EPI_SLAB_DEBUG|SLAB_PANIC,
NULL, NULL);
9
/* Allocates slab cache used to allocate “struct eppoll_entry” */
pwq_cache = kmem_cache_create(“eventpoll_pwq”,
sizeof(struct eppoll_entry), 0,
EPI_SLAB_DEBUG|SLAB_PANIC, NULL, NULL);
14
15 … …

epoll的高效就在于，当我们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的句柄给我们用户。这是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。
而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已，如何能不高效？！
那么，这个准备就绪list链表是怎么维护的呢？当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。
如此，一颗红黑树，一张准备就绪句柄链表，少量的内核cache，就帮我们解决了大并发下的socket处理问题。执行epoll_create时，创建了红黑树和就绪链表，执行epoll_ctl时，如果增加socket句柄，则检查在红黑树中是否存在，存在立即返回，不存在则添加到树干上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时立刻返回准备就绪链表里的数据即可。
最后看看epoll独有的两种模式LT和ET。无论是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在以后调用epoll_wait时次次返回这个句柄，而ET模式仅在之一次返回。
这件事怎么做到的呢？当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时我们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，然后清空准备就绪list链表，最后，epoll_wait干了件事，就是检查这些socket，如果不是ET模式（就是LT模式的句柄了），并且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表了。所以，非ET的句柄，只要它上面还有事件，epoll_wait每次都会返回。而ET模式的句柄，除非有新中断到，即使socket上的事件没有处理完，也是不会次次从epoll_wait返回的。

1 /*
2 * Each file descriptor added to the eventpoll interface will
3 * have an entry of this type linked to the hash.
4 */
5 struct epitem {
/* RB-Tree node used to link this structure to the eventpoll rb-tree */
struct rb_node rbn;
//红黑树，用来保存eventpoll
/* List header used to link this structure to the eventpoll ready list */
struct list_head rdllink;
//双向链表，用来保存已经完成的eventpoll
/* The file descriptor information this item refers to */
struct epoll_filefd ffd;
//这个结构体对应的被监听的文件描述符信息
/* Number of active wait queue attached to poll operations */
int nwait;
//poll操作中事件的个数
/* List containing poll wait queues */
struct list_head pwqlist;
//双向链表，保存着被监视文件的等待队列，功能类似于select/poll中的poll_table
/* The “container” of this item */
struct eventpoll *ep;
//指向eventpoll，多个epitem对应一个eventpoll
/* The structure that describe the interested events and the source fd */
struct epoll_event event;
//记录发生的事件和对应的fd
/*
* Used to keep track of the usage count of the structure. This avoids
* that the structure will desappear from underneath our processing.
37 */
atomic_t usecnt;
//引用计数
/* List header used to link this item to the “struct file” items list */
struct list_head fllink;
双向链表，用来链接被监视的文件描述符对应的struct file。因为file里有f_ep_link,用来保存所有监视这个文件的epoll节点
/* List header used to link the item to the transfer list */
struct list_head txlink;
双向链表，用来保存传输队列
/*
* This is used during the collection/transfer of events to userspace
* to pin items empty events set.
52 */
unsigned int revents;
//文件描述符的状态，在收集和传输时用来锁住空的事件
55 };
57 //该结构体用来保存与epoll节点关联的多个文件描述符，保存的方式是使用红黑树实现的hash表.
58 //至于为什么要保存，下文有详细解释。它与被监听的文件描述符一一对应.
59 struct eventpoll {
/* Protect the this structure access */
rwlock_t lock;
//读写锁
/*
* This semaphore is used to ensure that files are not removed
* while epoll is using them. This is read-held during the event
* collection loop and it is write-held during the file cleanup
* path, the epoll file exit code and the ctl operations.
69 */
struct rw_semaphore sem;
//读写信号量
/* Wait queue used by sys_epoll_wait() */
wait_queue_head_t wq;
/* Wait queue used by file->poll() */
wait_queue_head_t poll_wait;
/* List of ready file descriptors */
struct list_head rdllist;
//已经完成的操作事件的队列。
/* RB-Tree root used to store monitored fd structs */
struct rb_root rbr;
//保存epoll监视的文件描述符
86 };
关于linux sleep select的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
