使用的是宝塔管理面板。
但是由于服务器使用的是1核1G，
运行一段时间后发现服务器经常内存、CPU占用特别高导致服务器宕机
（也不知道是不是有人在ddos攻击我的服务器，反正有很多尝试访问不存在的url请求，估计是在探测扫描可能存在的后面地址）。
就1核CPU+1G内存来说但凡是个有心人要搞你，基本上网站很难防的住，但是有时候如果数据库查询过慢又没有进行一些其他缓存加速类的优化，在同时访问人数较多的情况下网站响应会很慢！昨天趁着有空在网上找了些1G内存mysql参数调优的文章，最终修改了mysql的一些参数，感觉内存及cpu占用还是有所下降。
文章来源地址https://www.toymoban.com/diary/apps/222.html
先记录，后整理
文章来源：https://www.toymoban.com/diary/apps/222.html
修改了这两个配置参数 interactive_timeout=120 和 wait_timeout =120
[client] #password = your_password port = 3306 socket = /tmp/mysql.sock [mysqld] binlog_cache_size = 32K thread_stack = 256K join_buffer_size = 256K query_cache_type = 1 max_heap_table_size = 64M port = 3306 socket = /tmp/mysql.sock datadir = /www/server/data default_storage_engine = InnoDB performance_schema_max_table_instances = 400 table_definition_cache = 400 skip-external-locking key_buffer_size = 16M max_allowed_packet = 100G table_open_cache = 256 sort_buffer_size = 1024K net_buffer_length = 4K read_buffer_size = 1024K read_rnd_buffer_size = 256K myisam_sort_buffer_size = 4M thread_cache_size = 32 query_cache_size = 32M interactive_timeout=120 tmp_table_size = 64M sql-mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES explicit_defaults_for_timestamp = true #skip-name-resolve max_connections = 120 max_connect_errors = 100 open_files_limit = 65535 wait_timeout =120 log-bin=mysql-bin binlog_format=mixed server-id = 1 expire_logs_days = 10 slow_query_log=1 slow-query-log-file=/www/server/data/mysql-slow.log long_query_time=3 #log_queries_not_using_indexes=on early-plugin-load = "" innodb_data_home_dir = /www/server/data innodb_data_file_path = ibdata1:10M:autoextend innodb_log_group_home_dir = /www/server/data innodb_buffer_pool_size = 64M innodb_log_file_size = 5M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_max_dirty_pages_pct = 90 innodb_read_io_threads = 1 innodb_write_io_threads = 1 [mysqldump] quick max_allowed_packet = 500M [mysql] no-auto-rehash [myisamchk] key_buffer_size = 20M sort_buffer_size = 20M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout
interactive_timeout: MySQL服务器关闭交互式连接前等待的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。参数默认值：28800秒（8小时） wait_timeout: MySQL服务器关闭非交互连接之前等待的秒数。在会话启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型--由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义。参数默认值：28800秒（8小时）
网上能搜到很多关于mysql中的wait_timeout相关的文章，但是大多数只是说明了他的作用，而且都说这个参数要配合那个interactive_timeout参数一起修改才会生效，经过今天我和同事的努力，这里要说一下，其实是我把同事坑了，很惭愧，之前只是看服务器上连接mysql的连接很多都是timewait状态，逐在网上搜索到这个wait_timeout参数，使用该参数后，果然很有效，大大抑制了很多无效的timewait，但是谁知道这个参数会影响后端程序的连接，至于原因，后面会说。
为什么会说网上大多数都是坑呢？因为这个wait_timeout并不是改了配置文件不起作用，也不是非要和那个interactive_timeout一起改，才会生效，只是你在配置文件中配置“wait_timeout = 10”，在mysql里，用show variables like "%timeout%"看到的还是28800
这个wait_timeout的作用是，设置非交互连接（就是指那些连接池方式、非客户端方式连接的）的超时时间，默认是28800，就是8小时，超过这个时间，mysql服务器会主动切断那些已经连接的，但是状态是sleep的连接。
而我们后端程序是运行在windows下的，所以安装的myodbc，并使用ado方式连接的，也就是连接池方式，这种方式的坏处是，当服务器端去连接mysql的时候，连接池里的连接已经被mysql主动断开，这时取回的连接就是null，再加上程序里对此没有做判断的话，接下来的对数据库的一系列的操作都会出现问题。
反正就是很坑，唉，说多了都是泪。
到此这篇关于低配置服务器Mysql如何优化,1核1G内存云服务器内存占用过大参数优化的文章就介绍到这了,更多相关内容可以在右上角搜索或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
