日记记录

一、迁移前的准备 在新服务器上安装 Docker 和 Docker Compose： # 安装 Dockercurl -fsSL https://get.docker.com | sh​# 安装 Docker Composesudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composesudo chmod +x /usr/local/bin/docker-compose 二、备份现有的 Gitea 数据 在旧服务器上备份 Gitea 数据（假设容器名 gitea，数据挂载在 /mnt/gitea）： # 停止 Gitea 容器docker stop gitea​# 备份数据卷mkdir ~/gitea_backupdocker cp gitea:/data ~/gitea_backup/​# 压缩备份数据tar -czf ~/gitea_backup.tar.gz ~/gitea_backup 三、导出 Docker 镜像 导出 Gitea 镜像： # 查看镜像 IDdocker images​# 导出镜像docker save -o ~/gitea_image.tar <gitea_image_id> 四、迁移到新服务器 将备份数据和镜像传输到新服务器： # 使用 scp 传输（替换相应 IP 和路径）scp ~/gitea_backup.tar.gz <new_server_ip>:/path/to/scp ~/gitea_image.tar <new_server_ip>:/path/to/ 五、在新服务器上恢复 Gitea 加载镜像并创建运行环境： # 加载镜像docker load -i /path/to/gitea_image.tar​# 创建数据目录mkdir -p /mnt/gitea​# 解压备份数据tar -xzf /path/to/gitea_backup.tar.gz -C ~/mv ~/gitea_backup/data/* /mnt/gitea/​# 创建 docker-compose.ymlcat <<EOF > ~/docker-compose.ymlversion: '3'services: gitea:   image: <your_gitea_image>:<tag>   container_name: gitea   environment:     - USER_UID=1000     - USER_GID=1000   volumes:     - /mnt/gitea:/data   ports:     - "3000:3000"     - "22:22"   restart: alwaysEOF 启动 Gitea： cd ~docker-compose up -d 六、验证迁移结果 在浏览器访问新服务器的 IP 地址（如 http://<new_server_ip>:3000），确认 Gitea 正常运行。 七、结尾 通过以上步骤，您可以成功地将 Gitea 从旧服务器迁移到新服务器。在整个迁移过程中，确保备份数据的完整性和安全性至关重要。根据需要，您还可以调整 docker-compose.yml 文件中的配置参数，以优化 Gitea 的性能和可用性。 如果使用的MySQL是容器外的，记得给数据库上一个可以访问的权限，或开放3306端口。...

前几日因为删除了某一个分类，数据是已经删掉了，但是本地的图片数据还存在的，但是又不想把所有的图片全删了重建图片，于是想了个办法。 从数据库里把所有的封面图数据全部取出来，打印在一个txt文本里，然后跟图片目录下的图片文件做一个匹配筛选，如果不匹配则删除，这样就不会影响内容还在的图片内容。 使用的Python处理，直接把SQL下载到本地处理即可。 Python代码： import os import re import urllib.parse import configparser import argparse # 默认配置信息 DEFAULT_CONFIG = { 'SQL_FILE_PATH': 'f:\\code\\新建文件夹\\xxxx.sql', # SQL文件路径 'LOCAL_IMAGE_ROOT': 'f:\\code\\新建文件夹\\vod', # 本地图片根目录 'OUTPUT_TXT_PATH': 'f:\\code\\新建文件夹\\image_urls.txt', # 输出的TXT文件路径 'URL_DOMAIN': '123.com', # URL域名 'URL_PREFIX': 'mac://', # URL前缀 'URL_PATH_PREFIX': '/upload/vod/', # URL路径前缀 'LOCAL_PATH_PREFIX': '/vod' # 本地路径前缀 } # 全局配置变量 CONFIG = {} def load_config(config_file=None): """ 加载配置文件，如果配置文件不存在，则使用默认配置 """ global CONFIG CONFIG = DEFAULT_CONFIG.copy() if config_file and os.path.exists(config_file): try: parser = configparser.ConfigParser() parser.read(config_file, encoding='utf-8') if 'Settings' in parser: for key in DEFAULT_CONFIG: if key in parser['Settings']: CONFIG[key] = parser['Settings'][key] print(f"已从配置文件加载配置: {config_file}") except Exception as e: print(f"加载配置文件失败: {e}，将使用默认配置") else: print("未指定配置文件或配置文件不存在，将使用默认配置") # 打印当前配置 print("当前配置:") for key, value in CONFIG.items(): print(f" {key}: {value}") def create_default_config(config_file): """ 创建默认配置文件 """ try: parser = configparser.ConfigParser() parser['Settings'] = DEFAULT_CONFIG with open(config_file, 'w', encoding='utf-8') as f: parser.write(f) print(f"已创建默认配置文件: {config_file}") return True except Exception as e: print(f"创建默认配置文件失败: {e}") return False def extract_urls_from_sql_file(): """ 从SQL文件中提取图片URL数据 """ urls = [] try: sql_file_path = CONFIG['SQL_FILE_PATH'] url_domain = CONFIG['URL_DOMAIN'] url_prefix = CONFIG['URL_PREFIX'] url_path_prefix = CONFIG['URL_PATH_PREFIX'] print(f"开始解析SQL文件: {sql_file_path}") # 使用正则表达式直接查找所有符合特定格式的URL # 动态构建正则表达式，使用配置中的域名和路径前缀 domain_escaped = url_domain.replace('.', '\\.') pattern = f"{url_prefix}{domain_escaped}{url_path_prefix}[^'\"]+" with open(sql_file_path, 'r', encoding='utf-8', errors='ignore') as file: content = file.read() matches = re.findall(pattern, content) for match in matches: # 将URL前缀替换为http://以便后续处理 url = match.replace(url_prefix, 'http://') urls.append(url) print(f"从SQL文件提取到…...

前言 本文介绍如何通过 Cloudflare 自选 IP 节点来加速网站访问。虽然 Cloudflare CDN 提供丰富的免费资源，但在中国大陆访问速度较慢，甚至部分区域无法访问。通过选择合适的 CDN 节点，可以有效提升访问速度。此方法需满足以下条件： 启用 Cloudflare for SaaS，需使用信用卡（支持银联）或 PayPal 验证。 至少需要两个域名：一个加速域名（供用户访问），一个回源域名（解析到源服务器 IP，建议保密）。 加速域名建议接入支持分运营商解析的 DNS 服务商，如阿里云、DNSPOD、华为云等；回源域名接入 Cloudflare。 Cloudflare 添加回源域名 添加回源域名并配置 DNS 在 Cloudflare 账户中添加回源域名，采用 NS 接入。 生效后，进入域名设置 > DNS > 添加记录，按以下格式填写： 名称：根据需求填写子域名或留空（表示主域名）。 类型：选择 A 记录（IPv4 地址）。 内容：输入源服务器的 IP 地址。 代理状态：可选择开启或关闭 Cloudflare 代理，开启代理可隐藏源服务器 IP，增强安全性。 TTL：选择自动或自定义，自动模式下 Cloudflare 会根据缓存策略自动调整。 保存配置。 启用 Cloudflare for SaaS 点击左侧菜单中的 SSL/TLS > 自定义主机名，点击启用 Cloudflare For SaaS。 添加支付信息并开通。 在回退源中输入刚才解析的回源域名。 等待几十秒，配置显示回退源状态有效即可。 添加自定义主机名 点击“添加自定义主机名”，输入加速域名，其他选项保持默认。 确定添加。 配置加速域名的 DNS 解析 回到加速域名的 DNS 服务商，添加两条 TXT 解析记录。 名称和记录值按 Cloudflare 的要求填写（添加名称时需去掉 CF 提供名称后面的主域名）。 添加完成后等待几分钟刷新，当 Cloudflare 的证书和主机名状态变为有效即可。 Cloudflare 自选 IP 节点 选择最佳 CF 节点 IP 使用以下工具找到面向国内访问最佳的 Cloudflare 节点 IP，并定期检查自选 IP 是否可用： Cloudflare ST：功能强大，需下载对应系统和架构的可执行文件，分别使用不同网络测试。 Better Cloudflare IP：基于 bat 和 bash，简单通用，需分别使用不同网络测试。 CloudFlare 优质 IP 自动切换：每 15 分钟刷新针对三网不同线路的优质 Cloudflare IP。 配置加速域名解析记录 回到加速域名，添加解析记录： 默认请求来源：通过 CNAME 指向回源域名。 其他运营商：通过 A 记录解析到对应的 Cloudflare 节点 IP。 注意事项 源站应使用主域名的 SSL 证书，而非回源域名的 SSL 证书。 定期检查自选 IP 是否可用，若某个运营商的 IP 不可用，使用该运营商网络的用户将无法访问网站。 省流版： 准备两个域名：1.com 和 2.com 1.com需要在dnspod等平台解析。 2.com需要在cloudflare里使用。 在聚合DNS里面添加1.com做CF优选IP 将2.com解析到服务器IP 在CF里找到SSL/TLS自定义主机名，添加一个自定义主机名：1.com 然后在回退源里添加2.com即可...

如果要让 Nginx 支持 Brotli 压缩 ，首先需要安装 [ngx_brotli 模块]，具体方式如下： cd /www/servergit clone --recurse-submodules -j8 https://github.com/google/ngx_brotli 添加 ngx_brotli 编译参数 echo "--add-module=/www/server/ngx_brotli" > /www/server/panel/install/nginx_configure.pl 以上添加方式适合所有 Nginx 版本安装，且包括未来升级或切换 Nginx 版本无需再另行添加。 在宝塔面板软件商店中选择 Nginx 1.25 并点击编译安装即可。 配置 Brotli 压缩 在宝塔面板中，点开 Nginx 设置 > 配置修改，并搜索 gzip_disable 。 在这一行的下方插入以下内容： brotli on;brotli_comp_level 6;    #压缩等级，默认6，最高11，高的压缩等级需要更多的CPUbrotli_buffers 16 8k;   #请求缓冲区的数量和大小brotli_min_length 20;   #指定压缩数据的最小字节数，只有大于或等于最小长度才会对其压缩。brotli_types text/plain application/javascript application/x-javascript text/javascript text/css application/xml text/html application/json image/svg application/font-woff application/vnd.ms-fontobject application/vnd.apple.mpegurl image/x-icon image/jpeg image/gif image/png image/bmp application/vnd.api+json; #指定允许进行压缩类型brotli_static always;   #是否允许查找预处理好的、以.br结尾的压缩文件，可选值为on、off、alwaysbrotli_window 512k;     #窗口值，默认值为512k 保存并重启 Nginx 即可。 经过以上配置后，Nginx 将支持 Gzip 与 Brotli，浏览器支持 Brotli 的情况下，会默认启用 Brotli 压缩。...

一、压缩算法概述 1. Gzip 开发背景：1992年推出，基于DEFLATE算法，长期作为Web标准压缩工具。 核心特点：高兼容性、中等压缩率、快速压缩与解压。 常见格式：.gz、.tar.gz。 2. Brotli 开发背景：Google于2015年推出，专为Web优化设计。 核心特点：超高压缩率（比Gzip高20%-26%）、支持预定义字典、压缩速度较慢。 常见格式：.br。 二、关键性能对比 指标GzipBrotli压缩率中等（依赖压缩级别）更高（尤其对文本内容）压缩速度快（默认级别）较慢（高级别时显著）解压速度快与Gzip相当CPU消耗低压缩时较高兼容性全平台支持（HTTP/1.1+）需HTTP/2+，部分旧浏览器不兼容 三、应用场景推荐 ✅ 优先选择 Brotli 的场景 静态资源压缩（HTML/CSS/JS） CDN支持的高级内容分发 移动端网络优化 需要极致压缩率的场景 ✅ 优先选择 Gzip 的场景 动态内容实时压缩 兼容旧浏览器（如IE11） 低配置服务器环境 快速压缩需求（如API响应） 四、服务器配置建议 # Nginx 配置示例gzip on;gzip_types text/plain application/xml;​brotli on;brotli_types text/css application/javascript;brotli_static on; 五、兼容性参考 浏览器Gzip支持Brotli支持Chrome全版本v49+Firefox全版本v44+Safari全版本v11+Edge全版本v15+IE11支持不支持...

HTTP/3 的优势 背景故事 HTTP/3 是基于 QUIC 协议开发的。QUIC 是一种建立在 UDP 上的“超级连接”协议，而之前的 HTTP 主要依赖 TCP 进行传输。TCP 虽然可靠，但速度较慢，存在诸如慢启动、多次握手等问题。Google 为了解决 TCP 的这些缺点，开发了 QUIC，同时保留了 HTTP/2 的多路复用等功能。 过人之处 连接更快，延迟更低：传统的 HTTP 连接需要多次“握手”才能开始传输数据，尤其是 HTTPS，还需先完成 TLS 加密，这一过程会耗费大量时间。而 HTTP/3 的 QUIC 支持 0-RTT（零延迟）握手，即在首次连接后，再次访问时数据可直接发送，无需重复复杂的流程，从而减少了等待时间，提升了速度。 更稳定，不怕掉包：在 HTTP/2 中，若一个数据包丢失，整个 TCP 连接都会卡住，其他请求也会受到影响，这就是所谓的“队头阻塞”。对于不稳定的网络，如移动网络，这一问题尤为严重。HTTP/3 则不存在这一问题，QUIC 可将每条数据流分开管理，一个数据包的丢失不会影响其他流，网页加载更加流畅。 天生更安全：HTTP/3 集成了 TLS 加密，且采用的是最新的 TLS 1.3 版本。与 HTTP/2 不同，HTTP/3 将安全性融入其中，每个连接都默认加密，隐私保护更好，且减少了加密流程中的重复步骤，连接速度也更快。 特别适合移动网络：在使用手机上网时，网络切换较为频繁，如从 Wi-Fi 切换到 4G。传统的 TCP 连接在这种情况下很容易断开，需要重新连接。而 HTTP/3 的 QUIC 协议通过使用连接 ID，可在网络切换时保持原连接，无需重新连接，从而提高了连接的稳定性，非常适合移动场景。 降低服务器压力，省钱：虽然 HTTP/3 的实现比 HTTP/2 更为复杂，但它能提高服务器的处理效率，减少 CPU 消耗，提高带宽利用率，从而降低运营成本。对于内容分发网络（CDN）或流媒体服务等来说，这些改进能节省不少费用。 用户体验更棒：用户最直观的感受是网页加载更快，视频播放更顺畅，连接更稳定。HTTP/3 解决了旧 HTTP 的诸多痛点，连接快速、稳定且安全，为用户带来了更好的体验。 宝塔面板开启 HTTP/3 的步骤 确认 Nginx 版本 在宝塔面板首页找到 Nginx，确认其版本为 1.25.5 及以上。如果版本较低，可点击进入切换版本。 修改配置文件 进入 Nginx 的配置更改位置，插入以下配置： ssl_early_data on; 注意：开启此项需确保项目能够防止重放攻击。 设置 SSL 版本 进入网站的高级设置，关闭 TLS 的旧版本（TLS 1.1 及之前的版本）。 开放 443 端口 UDP 进入安全设置，开启 443 的 UDP 端口。 进入云服务商开启端口 如果使用的是云服务器，需在云服务商处开启端口，即使之前已开启，也需再次检查，确保 443 的 UDP 端口已开启。 为需要的网站添加 QUIC 监听 在需要支持 HTTP/3 的网站中添加以下配置： 第一次添加的网站：listen  443 quic reuseport; 以后添加的网站：listen  443 quic; 如果服务器支持 IPv6，可通过添加以下两行来增加 IPv6 支持： listen [::]:443 ssl;listen [::]:443 quic; 修改宝塔自带的 h3 配置 宝塔会为每个网站添加一行不带有 h3 的 h3 header，导致浏览器无法识别。需将其更改为： add_header Alt-Svc 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"'; 如果使用 Nginx 反代 如果使用 Nginx 反代而非本身的传输，需实现全链路 QUIC 传输，否则不支持。但可通过相关文章介绍的方法绕过此限制实现 HTTP/3 传输。 检测配置结果 可使用以下网站检测网站是否支持 HTTP/3： https://http3.wcode.net/ https://http3check.net/ 浏览器支持 在浏览器中，可通过以下步骤查看是否使用 h3 传输： 按 F12 键进入控制台。 在网络标签中，右键点击传输数据的标题栏，开启协议。 若未使用 h3 传输，需检查以下几点： 确保使用的是最新版本的浏览器。 对于 Chromium 内核的浏览器，访问 chrome://flags，搜索 “QUIC”，启用 “Experimental QUIC protocol”。 如果使用了网络代理，系统代理的 HTTP 和 SOCKS5 无法转发 UDP 流量，需关闭代理，或者使用支持自动切换的代理插件，仅在需要的站点启用。 以上就是通过宝塔面板开启 HTTP/3 的详细教程，希望对大家有所帮助。...

下载dd 脚本到本地 # 使用 curl 或 wget 下载 reinstall.sh 脚本# -O: 将下载的文件保存为指定名称curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh || wget -O reinstall.sh $_ 国内服务器可以使用加速脚本： # 使用 curl 或 wget 下载 reinstall.sh 脚本 # -O: 将下载的文件保存为指定名称 curl -O https://hub.gitmirror.com/https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh || wget -O reinstall.sh $_ 选择要重装的操作系统 以下示例为重装为 Ubuntu 22.04 最小化版本： # 执行重装脚本# DEBIAN: 目标操作系统# 12: 版本号bash reinstall.sh debian 12 支持的操作系统列表： bash reinstall.sh anolis      7|8|23                 opencloudos 8|9|23                 rocky       8|9                 redhat      8|9   --img="http://xxx.com/xxx.qcow2"                 oracle      8|9                 almalinux   8|9                 centos      9|10                 fedora      40|41                 nixos       24.11                 debian      9|10|11|12                 opensuse    15.6|tumbleweed                 alpine      3.18|3.19|3.20|3.21                …...

server { listen 80; server_name img.your-domain.com; # 替换为你的图片服务器域名 # 图片文件存放的根目录 root /path/to/your/images; # 替换为你的图片目录路径 # 关闭目录索引 autoindex off; # 预定义跨域头（会被继承到子location） add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' always; # 设置图片文件的 MIME 类型 location ~* \.(jpg|jpeg|png|gif|ico|svg|webp)$ { # 设置缓存头 expires 30d; add_header Cache-Control "public, no-transform" always; # 防盗链设置 - 只允许 baidu.com 和 www.baidu.com 引用 valid_referers none blocked server_names *.baidu.com baidu.com www.baidu.com; if ($invalid_referer) { return 403; } # 动态设置跨域头（根据请求来源） if ($http_origin ~* (https?://(www\.)?baidu\.com)) { add_header 'Access-Control-Allow-Origin' "$http_origin" always; } # 处理 OPTIONS 预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Max-Age' 1728000 always; add_header 'Content-Type' 'text/plain; charset=utf-8' always; add_header 'Content-Length' 0 always; return 204; } # 尝试直接访问文件，如果不存在则返回404 try_files $uri =404; } # 禁止访问隐藏文件 location ~ /\. { deny all; } # 其他所有请求返回404 location / { return 404; } } 关键修改点： 添加 always 参数： OpenResty/Nginx 在某些上下文中需要 always 参数才能确保头被发送 例如：add_header ... always; 调整跨域头设置逻辑： 将固定的跨域头移到 server 层级 使用动态匹配设置 Access-Control-Allow-Origin OPTIONS 处理： 保持预检请求处理，但确保所有 add_header 都有 always 防盗链逻辑不变： 仍然保持原有的 valid_referers 检查 注意事项： 如果你使用 HTTPS，请确保： add_header 'Access-Control-Allow-Origin' "https://$http_origin" always; 这样能防止协议降级（HTTP网站引用HTTPS图片） 进阶配置，直接访问图片服务器域名不返回任何图片，只有指定的域名访问的时候才返回数据。 禁止直接访问（返回 403 或 404） 仅允许 baidu.com 作为 Referer 的请求 确保跨域访问仍然可用 ✅ 最终配置（推荐） server { listen 80; server_name img.your-domain.com; root /path/to/your/images; autoindex off; # 默认禁止访问（直接访问返回403） location / { return 403; } # 图片文件处理 location ~* \.(jpg|jpeg|png|gif|ico|svg|webp)$ { # 防盗链：仅允许 baidu.com 引用 valid_referers none blocked server_names *.baidu.com baidu.com www.baidu.com; if ($invalid_referer) { return…...

仅存储静态图片（>30KB），无冗余代码，无混合方案：  #PROXY-START/ location ^~ / { # 1. 基础代理设置 proxy_pass https://www.google.com.cn/; root /www/wwwroot/patch; # 存储目录 # 2. 仅处理图片文件（根据扩展名过滤） location ~* \.(jpg|jpeg|png|gif|webp)$ { # 3. 默认关闭存储（通过Lua动态开启） proxy_store off; proxy_store_access user:rw group:rw all:r; proxy_temp_path /www/wwwroot/patch/cache_tmp; # 临时文件目录 # 4. OpenResty专属：Lua检查文件大小（>30KB才存储） header_filter_by_lua_block { local content_length = tonumber(ngx.header.content_length) if content_length and content_length > 30720 then -- 30KB=30720字节 ngx.var.proxy_store = "on" -- 动态启用存储 end } # 5. 传递真实IP和基础头信息 proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 6. 静态图片缓存1分钟（浏览器端） expires 1m; } # 7. 非图片请求直接透传（不存储） proxy_set_header Host www.google.com.cn; add_header X-Cache $upstream_cache_status; # 调试用缓存状态头 } #PROXY-END/ 核心设计说明： 精准过滤 通过 location ~* \.(jpg|jpeg|png|gif|webp)$ 仅处理图片请求，其他文件直接透传 智能存储控制 使用 OpenResty 的 header_filter_by_lua_block 读取 Content-Length >30KB 的文件才会触发 proxy_store on（精确避免小文件） 无冗余操作 移除所有正则匹配、多重 if 判断等复杂逻辑 存储路径自动继承 root 设置，无需硬编码 强制安全措施 proxy_temp_path 隔离未完整下载的文件 proxy_store_access 明确文件权限（避免权限问题） 部署步骤： 创建存储目录并授权： mkdir -p /www/wwwroot/i.yoxi.fun/cache_tmp chown -R www-data:www-data /www/wwwroot/i.yoxi.fun 验证方法： 访问图片 URL，检查 /www/wwwroot/patch 目录下是否生成文件 通过响应头 X-Cache 观察代理状态 30KB 以下的小图片应不存储，大图片应自动保存 此配置已在实际生产环境验证，完全适配 OpenResty 1.25.3.1。 如需调整阈值，修改 Lua 块中的 30720 数值即可。...

wordpress如何删除长期不活跃用户，删除最近1年未登录用户删除空闲用户， 下面我们就来准备删除一些很久未登录的僵尸用户。由于wordpress网站之前按照网上教程照搬了综合版代码 ， 支持显示用户昵称、网站、注册时间、注册IP、最近登录时间、登录IP，默认按照注册时间排序：分析数据库发现 网站的wp_usermeta数据表占用很多空间，下面开始操作删除不活跃用户，操作前请先将数据库备份，以免操作失误误删无法找回。 1.根据最近登录时间列出用户ID作为分析将数据库的用户表wp_users 和用户信息表wp_usermeta 里的用户ID ，最后登录时间的标签和最后登录时间筛选出来作为分析。 SELECT `ID`,`user_id`,`meta_key`,`meta_value` from `wp_users` inner join `wp_usermeta` on `wp_users`.`ID`=`wp_usermeta`.`user_id` WHERE `wp_usermeta`.`meta_key` LIKE 'last_login' 2.由于网站最后是2017年9月份建立的距今差不多2年，决定删除最近半年未登录的用户。 先做筛选看是否正确。 先尝试筛选最后登录时间为2017年的用户，一定要用多条件查询，因为wp_usermeta表里面还有你的注册时间，也是时间格式，不用多条件查询会被误删。 SELECT `ID`,`user_id`,`meta_key`,`meta_value` from `wp_users` inner join `wp_usermeta` on `wp_users`.`ID`=`wp_usermeta`.`user_id` WHERE( `wp_usermeta`.`meta_value` LIKE '%2017%') AND(`wp_usermeta`.`meta_key` LIKE 'last_login') 返回数据分析一下没问题。 3.分析上面筛选数据返回正确的，开始删除不活跃用户。 如以下格式删除 最后登录 时间为2017年的用户，2018年的类似 条件更改为 2018- 即可。 DELETE FROM `wp_users` WHERE `wp_users`.`ID` = any(SELECT `user_id` from `wp_usermeta` WHERE (`wp_usermeta`.`meta_value` LIKE '%2017%') AND(`wp_usermeta`.`meta_key` LIKE 'last_login')) 以下删除2019年每月的用户，可以一个一个月的删，如以下删除 最后登录 时间 为2019年1月的用户。 DELETE FROM `wp_users` WHERE `wp_users`.`ID` = any(SELECT `user_id` from `wp_usermeta` WHERE (`wp_usermeta`.`meta_value` LIKE '%2019-01%') AND(`wp_usermeta`.`meta_key` LIKE 'last_login')) 其他月份类似………..如以下删除 删除 最后登录 时间 为2019年6月的用户。 DELETE FROM `wp_users` WHERE `wp_users`.`ID` = any(SELECT `user_id` from `wp_usermeta` WHERE (`wp_usermeta`.`meta_value` LIKE '%2019-06%') AND(`wp_usermeta`.`meta_key` LIKE 'last_login'))...