找到
5
篇与
MySQL
相关的结果
-
Typecho 一键清理数据库中的垃圾数据 Typecho博客系统因其轻量简洁而备受青睐，但其自定义字段功能却存在一个潜在问题：缺乏自动回收机制。这意味着每次发布文章，即使没有用到新的自定义字段，系统依然会为文章生成相应的空字段记录。日积月累，这些无用的数据会像垃圾一样堆积在数据库中，最终导致数据库膨胀，查询速度变慢，甚至影响整个博客的运行效率。想象一下，几百篇文章后，数据库里积累了数千行甚至上万行毫无意义的自定义字段数据，这无疑是对服务器资源的一种浪费。 幸运的是，这个问题并非无解。无需复杂的数据库操作或插件安装，只需执行一段简单的 SQL 代码，即可一键清理这些冗余的自定义字段数据，为你的 Typecho 博客瘦身，恢复其应有的运行速度和流畅体验。这将有效释放数据库空间，提升查询效率，让你的博客重焕青春。所以，如果你也面临着 Typecho 数据库膨胀的问题，不妨尝试一下这个便捷的解决方案。$[经典表情]::(斜眼笑) 以下代码回复可见 隐藏内容，请前往内页查看详情 宝塔用户可直接使用 phpMyAdmin 执行 phpMyAdmin执行SQL语句教程图片
-
不可不知的 MySQL 配置参数，让你的数据库 “稳如狗” 为了提高 MySQL 服务器的性能和稳定性，我们需要对其配置参数进行调整，主要包含 OS 配置参数和 MySQL 数据库配置参数，需要的小伙伴可以参考一下。 OS配置部分 （1）在BIOS及内核层面关闭NUMA （2）在BIOS层面将CPU、内存均设置最大性能模式 （3）在BIOS层面关闭CPU节能模式 （4）修改 IO Scheduler 为 deadline 或 noop，机械盘设置为 deadline，ssd 设置为 noop grep deadline /sys/block/sd*/queue/scheduler（5）使用xfs文件系统，挂载选项 noatime、nodiratime、nobarrier （6）在内核层面设置 vm.swappiness<=5，vm.dirty_ratio<=10， vm.dirty_background_ratio<=5 fs.file_max=65536 指定能够打开的文件句柄数 vm.dirty_background_ratio 指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台 回写进程运行，将一定缓存的脏页异步地刷入外存; vm.dirty_ratio 指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。 net.core.somaxconn=65536 指定socket监听的TCP协议连接数的上限 net.core.netdev_max_backlog=65536 net.ipv4.tcp_max_sync_backlog=65536 net.ipv4.tcp_fin_timeout=10 net.ipv4.tcp_tw_reuse=0 此参数表示开启重用，允许将 TIME_WAIT 套接字重新用于新的TCP连接 建议关闭 net.ipv4.tcp_tw_recycle=0 此参数表示开启TCP连接中 TIME_WAIT 的快速回收，建议关闭（7）在内核层面修改用户可最大打开文件数和线程数为 65535 vi /etc/security/limits.conf # add for mysql * - nofile 65535 * - nproc 65535MySQL配置部分 （1）sort/join/read/read rnd buffer 设置 --一般4M或者8M，最多到16M sort_buffer_size = 4M join_buffer_size = 4M read_buffer_size = 8M read_rnd_buffer_size = 4M （2）tmp/heap table --一般16M或者32M，如果sql性能差，需要经常产生临时表，可以设到96M。可以在session级别设置 tmp_table_size = 32M max_heap_table_size = 32M （3）双一保证 --保证主库环境、主从数据一致性 sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 （4）long_query_time --建议设为0.01-0.1，如果设为0，就会把所有的sql记录下来，需要定期去清理 long_query_time = 0.1 （5）log_queries_not_using_indexes & log_throttle_queries_not_using_indexes --把所有没有使用索引的sql都记录下来 log_queries_not_using_indexes =1 log_throttle_queries_not_using_indexes = 60 （6）interactive_timeout & wait_timeout --一般建议设置为300s 或者600s interactive_timeout = 600 wait_timeout = 600 （7）lock_wait_timeout --持有锁的时间，一般设置为1800或者3600 lock_wait_timeout = 3600 （8）default_time_zone --可能造成cpu使用高，要设置一个固定值 default_time_zone = "+8:00" （9）thread_handling --企业版或者percona版本才有的参数，如果业务是大量短连接，可以设置。如果是长连接或者连接池，没必要打开 （10）innodb_buffer_pool_size --一般设置为内存50%-75% innodb_buffer_pool_size=2G innodb_buffer_pool_instances 必须在 innodb_buffer_pool_size 大于等于1G 时才生效。 当 innodb_buffer_pool_size 值低于 1GB时，没必要也不能设置innodb_buffer_pool_instances 值大于等于 2。 一般而言，当 innodb_buffer_pool_size 值不高于 8GB时，没必要设置innodb_buffer_pool_instances 值大于 1。 通常，当 innodb_buffer_pool_size 较大时（大于64GB），innodb_buffer_pool_instances设置为 8 是个比较合理的值。 （11）innodb_max_dirty_pages_pct --默认75%，IO比较快的可设置为50% innodb_max_dirty_pages_pct = 50 （12）innodb_thread_concurrency --建议设置为0 innodb_thread_concurrency = 0 （13）innodb_lock_wait_timeout --行锁等待时间，设为5-10s innodb_lock_wait_timeout = 10 （14）innodb_log_file_size & innodb_log_files_in_group innodb_log_file_size = 2G innodb_log_files_in_group = 3 （15） # 根据您的服务器IOPS能力适当调整 # 一般配普通SSD盘的话，可以调整到 10000 - 20000，普通机械磁盘其随机IO的IOPS最多也就是300 # 配置高端PCIe SSD卡的话，则可以调整的更高，比如 50000 - 80000 innodb_io_capacity = 4000 innodb_io_capacity_max = 8000 （16） innodb_status_output innodb 状态监控信息开关，on为开启，off为关闭，默认为off innodb_status_output_locks 为锁监控信息开关，on为开启，off为关闭，默认也为off 一般建议将innodb_status_output innodb 参数关闭，如测试需要可以临时打开，测试完成再关闭。 SET GLOBAL innodb_status_output=OFF; 改为还需要同步修改配置文件，否则下次重启又打开了。改完后，错误日志不再有innodb状态信息输出了。 innodb_status_output_locks 设置为打开，监控锁信息。这样需要查看锁信息时，可以通过 show engine innodb status \G; 进行查看。 （17） skip_name_resolve：默认值为OFF，内网生产建议设为ON，禁用dns解析 （18）设置保存binlog时间 expire_logs_days=7 或者 binlog_expire_logs_seconds=604800 （19）sql_mode ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION （20）max_allowed_packet max_allowed_packet = 64M （21）innodb_print_all_deadlocks innodb_print_all_deadlocks=1 #建议打开
-
Love-Yi情侣网站存在SQL注入漏洞 FOFA介绍 部署在互联网上的网络设备资产信息搜索引擎。旨在尽可能多的对全球IT设备资 产进行信息收集、 漏洞扫描， 进而开展资产影响分析、漏洞影响分析, 为相关流行态势感知分析提供依据。 网址：https://fofa.info/ FOFA图片 漏洞复现 搜索 love-yi 再找到国内站点，访问速度快一点，提高渗透效率 图片 love-yi是一个记录情侣日常的恋爱网站，经某位程序员修改和设计之后，使其更加美观好看，适合哄女朋友开心，或者留作纪念。 图片 找到点点滴滴下的文章 图片 文章详细页面 图片 查看url，包含了一个id 图片 尝试注入，添加一个 ' ?id=6'查看源码，报错，存在SQL注入漏洞 图片 注入payload ?id=6' union select 1,2,3,4 -- qwe还是报错，而且文章内容也没了，说明该表字段不含4列，尝试5列 图片 ?id=6' union select 1,2,3,4,5 -- qwe正常显示，说明该表包含5个字段 图片 这里使用的union联结查询，他通常需要具备三个条件 选择的列数在两个查询中都是相同的。 数据类型在两个查询中都是兼容的。 第一个查询（即原始查询）不返回任何结果，或者你知道如何绕过它（例如，通过使WHERE子句始终为假）。 第三点中提到了原始查询不返回任何结果，得到payload ?id=-6' union select 1,2,3,4,5 -- qwe图片 注入成功，将2修改为如下payload // 拼接数据库版本，当前用户 concat(user(),database())图片 总结 由于作者更喜欢手工注入，因为手工注入更不容易被发现，灵活性，但是技术要求比较高，也比较耗时，使用SQL注入工具可以提高攻击效率和成功率，但也存在易被发现、受安全设备限制、需要特定环境、可能引发误报以及依赖工具更新等缺点。
-
ThinkPHP中日期时间区间查询以及whereTime用法 一、使用where方法进行时间的比较查询 where('create_time', '> time', '2021-8-8'); // 大于某个时间 where('create_time', '<= time', '2020-8-8'); // 小于某个时间 where('create_time', 'between time', ['2020-1-1', '2020-10-1']); // 时间区间查询二、使用whereTime方法 whereTime('birthday', '>=', '1970-10-1')->select(); // 大于某个时间 whereTime('birthday', '<', '2000-10-1')->select(); // 小于某个时间 whereTime('birthday', 'between', ['1970-10-1', '2000-10-1'])->select(); // 时间区间查询 whereTime('birthday', 'not between', ['1970-10-1', '2000-10-1'])->select(); // 不在某个时间区间三、时间表达式 // 获取今天的文章 Db::table('think_news')->whereTime('create_time', 'today')->select(); // 获取昨天的文章 Db::table('think_news')->whereTime('create_time', 'yesterday')->select(); // 获取本周的文章 Db::table('think_news')->whereTime('create_time', 'week')->select(); // 获取上周的文章 Db::table('think_news')->whereTime('create_time', 'last week')->select(); // 获取本月的文章 Db::table('think_news')->whereTime('create_time', 'month')->select(); // 获取上月的文章 Db::table('think_news')->whereTime('create_time', 'last month')->select(); // 获取今年的文章 Db::table('think_news')->whereTime('create_time', 'year')->select(); // 获取去年的文章 Db::table('think_news')->whereTime('create_time', 'last year')->select();四、如果查询当天、本周、本月和今年的时间，还可以简化为： // 获取今天的文章 Db::table('think_news')->whereTime('create_time', 'd')->select(); // 获取本周的文章 Db::table('think_news')->whereTime('create_time', 'w')->select(); // 获取本月的文章 Db::table('think_news')->whereTime('create_time', 'm')->select(); // 获取今年的文章 Db::table('think_news')->whereTime('create_time', 'y')->select();五、时间范围查询 // 查询两个小时内的文章 Db::table('think_news')->whereTime('create_time', '-2 hours')->select(); // 查询两天内的文章 Db::table('think_news')->whereTime('create_time', '-2 days')->select();
-
为什么不推荐在MySQL中使用UTF-8编码？ 记得去年我在往 MySQL 存入emoji表情😲😳时，一直出错，无法导入。后来找到办法 -- 通过把 utf8 改成 utf8mb4 就可以了，并没有深究。 一年后，我看到一篇文章讲到emoji文字占4个字节，通常要用utf-8去接收才行，其他编码可能会出错。我突然想到去年操作MySQL把utf8改成 utf8mb4 的事儿。 MySQL图片 嗯？他本身不就是utf8编码么！那我当时还改个锤子？ 难道，MySQL的utf8不是真正的 UTF-8 编码吗？？! 这。。MySQL有bug！ 带着疑问查询了很多相关材料，才发现这竟然是MySQL的一个历史遗留问题~~ 我笑了，没想到这么牛的MySQL也会有这段往事。 一、报错回顾 将emoji文字直接写入SQL中，执行 insert 语句报错； INSERT INTO `csjdemo`.`student` (`ID`, `NAME`, `SEX`, `AGE`, `CLASS`, `GRADE`, `HOBBY`); VALUES ('20', '陈哈哈😓', '男', '20', '181班', '9年级', '看片儿'); [Err] 1366 - Incorrect string value: '\xF0\x9F\x98\x93' for column 'NAME' at row 1 改了数据库编码、系统编码以及表字段的编码格式 → utf8mb4 之后，就可以了： INSERT INTO `student` (`ID`, `NAME`, `SEX`, `AGE`, `CLASS`, `GRADE`, `HOBBY`); VALUES (null, '陈哈哈😓😓', '男', '20', '181班', '9年级', );图片 二、MySQL中utf8的趣事 MySQL 的“utf8”实际上不是真正的 UTF-8。 在MySQL中，“utf8”编码只支持每个字符最多三个字节，而真正的 UTF-8 是每个字符最多四个字节。 在utf8编码中，中文是占3个字节，其他数字、英文、符号占一个字节。 但emoji符号占4个字节，一些较复杂的文字、繁体字也是4个字节。所以导致写入失败，应该改成 utf8mb4 MySQL 一直没有修复这个 bug，他们在 2010 年发布了一个叫作“utf8mb4”的字符集，巧妙的绕过了这个问题。 当然，他们并没有对新的字符集广而告之（可能是因为这个 bug 让他们觉得很尴尬），以致于现在网络上仍然在建议开发者使用“utf8”，但这些建议都是错误的。 1. utf8mb4 才是真正的UTF-8 是的，MySQL 的“utf8mb4”才是真正的“UTF-8”。 MySQL 的“utf8”是一种“专属的编码”，它能够编码的 Unicode 字符并不多。 在这里Mark一下：所有在使用“utf8”的 MySQL 和 MariaDB 用户都应该改用“utf8mb4”，永远都不要再使用“utf8” 那么什么是编码？什么是 UTF-8？ 我们都知道，计算机使用 0 和 1 来存储文本。比如字符“C”被存成“01000011”，那么计算机在显示这个字符时需要经过两个步骤： 计算机读取“01000011”，得到数字 67，因为 67 被编码成“01000011”。 计算机在 Unicode 字符集中查找 67，找到了“C”。 同样的： 我的电脑将“C”映射成 Unicode 字符集中的 67。 我的电脑将 67 编码成“01000011”，并发送给 Web 服务器。 几乎所有的网络应用都使用了 Unicode 字符集，因为没有理由使用其他字符集。 Unicode 字符集包含了上百万个字符。最简单的编码是 UTF-32，每个字符使用 32 位。这样做最简单，因为一直以来，计算机将 32 位视为数字，而计算机最在行的就是处理数字。但问题是，这样太浪费空间了。 UTF-8 可以节省空间，在 UTF-8 中，字符“C”只需要 8 位，一些不常用的字符，比如“😓”需要 32 位。其他的字符可能使用 16 位或 24 位。一篇类似本文这样的文章，如果使用 UTF-8 编码，占用的空间只有 UTF-32 的四分之一左右。 2. utf8 的简史 为什么 MySQL 开发者会让“utf8”失效？ 我们或许可以从MySQL版本提交日志中寻找答案。 MySQL 从 4.1 版本开始支持 UTF-8，也就是 2003 年，而今天使用的 UTF-8 标准（RFC 3629）是随后才出现的。 旧版的 UTF-8 标准（RFC 2279）最多支持每个字符 6 个字节。2002 年 3 月 28 日，MySQL 开发者在第一个 MySQL 4.1 预览版中使用了 RFC 2279。 同年 9 月，他们对 MySQL 源代码进行了一次调整：“UTF8 现在最多只支持 3 个字节的序列”。 是谁提交了这些代码？他为什么要这样做？这个问题不得而知。在迁移到 Git 后（MySQL 最开始使用的是 BitKeeper），MySQL 代码库中的很多提交者的名字都丢失了。2003 年 9 月的邮件列表中也找不到可以解释这一变更的线索。 不过我们可以试着猜测一下： 2002年，MySQL做出了一个决定：如果用户可以保证数据表的每一行都使用相同的字节数，那么 MySQL 就可以在性能方面来一个大提升。为此，用户需要将文本列定义为“CHAR”，每个“CHAR”列总是拥有相同数量的字符。如果插入的字符少于定义的数量，MySQL 就会在后面填充空格，如果插入的字符超过了定义的数量，后面超出部分会被截断。 MySQL 开发者在最开始尝试 UTF-8 时使用了每个字符6个字节，CHAR(1) 使用6个字节，CHAR(2)使用12个字节，并以此类推。 应该说，他们最初的行为才是正确的，可惜这一版本一直没有发布。但是文档上却这么写了，而且广为流传，所有了解 UTF-8 的人都认同文档里写的东西。 不过很显然，MySQL 开发者或厂商担心会有用户做这两件事： 使用 CHAR 定义列（在现在看来，CHAR 已经是老古董了，但在那时，在 MySQL 中使用 CHAR 会更快，不过从 2005 年以后就不是这样子了）。 将 CHAR 列的编码设置为“utf8”。 我的猜测是 MySQL 开发者本来想帮助那些希望在空间和速度上双赢的用户，但他们搞砸了“utf8”编码。 所以结果就是没有赢家。那些希望在空间和速度上双赢的用户，当他们在使用“utf8”的 CHAR 列时，实际上使用的空间比预期的更大，速度也比预期的慢。而想要正确性的用户，当他们使用“utf8”编码时，却无法保存像“😓”这样的字符，因为“😓”是4个字节的。 在这个不合法的字符集发布了之后，MySQL 就无法修复它，因为这样需要要求所有用户重新构建他们的数据库。最终， MySQL 在 2010 年重新发布了“utf8mb4”来支持真正的 UTF-8。 三、总结 主要是目前网络上几乎所有的文章都把 “utf8” 当成是真正的 UTF-8，包括之前我写的文章以及做的项目（捂脸）；因此希望更多的朋友能够看到这篇文章。 相信还有很多跟我在同一条船上的人，这是必然的。 所以，大家以后再搭建MySQL、MariaDB数据库时，记得将数据库相应编码都改为utf8mb4。
