基于mysql.connector的python打包exe能否在无mysql驱动PC运行，sqlite方案是否可行

第一个问题：打包带mysql.connector的应用，在无MySQL驱动的PC上能否正常连接 #

• 只要打包环节正确收拢了所有依赖，完全可以正常运行，目标PC不需要安装任何MySQL相关的系统组件：既不需要部署本地MySQL服务端，也不需要安装系统级ODBC驱动、MySQL客户端动态库。
• 核心原因：mysql.connector是纯Python实现的数据库驱动，不像mysqlclient这类依赖本地C动态库的驱动，不需要绑定系统层的运行时环境，打包时只要把对应的Python代码全部嵌入到可执行文件中，运行时就能直接调用完成连接逻辑。
• 常见的打包踩坑点：部分打包工具（比如PyInstaller）会自动漏识别mysql.connector的子模块，比如MySQL 8.0默认的caching_sha2_password认证逻辑对应的子模块，这种情况只要在打包参数里手动添加隐藏导入（比如--hidden-import=mysql.connector.plugins.caching_sha2_password）就能解决。
• 目标PC的最低运行要求只有两个：网络能正常连通到你要访问的MySQL服务器的IP和端口，系统能正常启动打包生成的可执行文件即可。

第二个问题：改用SQLite存到共享文件夹的方案可行性 #

• 基础功能层面完全可以实现：SQLite本身就是单文件嵌入式数据库，没有独立的后台服务，应用连接时只要把数据库路径指向局域网共享的UNC地址（比如\\文件服务器\共享目录\appdata.db），管理员随时可以直接拷贝这个文件读取、备份数据，不需要额外的数据库管理工具。
• 但这个方案有明确的适用边界，很容易踩坑，提前列清楚注意事项：
  • 锁机制兼容问题：SQLite原生的文件锁逻辑是面向本地磁盘设计的，在SMB共享目录下，跨设备的文件锁是不可靠的，当多台客户端同时对数据库执行写入操作时，极大概率出现database is locked的报错，极端场景下甚至会导致数据库文件损坏。
  • 性能问题：跨网络读写磁盘的延迟远高于本地磁盘，高频写入的场景下，吞吐量会比本地存储下降一个数量级；且SQLite的WAL日志模式在网络共享目录下兼容性极差，不建议开启。
  • 权限管控问题：没有内置的多用户访问控制逻辑，只要拿到共享路径的访问权限，就能直接修改、删除数据库文件，没有MySQL这类服务端数据库的细粒度账号、权限管控能力。
• 适用场景参考：如果是单局域网环境，客户端并发数少于5、写入操作频率低（比如每分钟数次数据写入，不是每秒级的高频写入）、网络连接稳定无波动，这个方案可以正常用，不需要额外搭建数据库服务。如果并发高、写入频繁，不建议采用这个架构。

内容的提问来源于stack exchange，提问作者cadmad