怎样在Python Flask中实现简单的搜索功能：利用SQL-LIKE模糊查询
在Web应用中，搜索功能几乎是标配。但一个看似简单的搜索框背后，从接收关键词到数据库查询，每一步都有讲究。今天，我们就来拆解一下，如何在Flask框架中安全、高效地实现基于SQL LIKE的模糊搜索。
Flask路由里怎么接收搜索关键词
搜索请求通常通过URL的查询参数传递，例如用户访问 /search?q=python。这里的关键，是使用 request.args.get('q', '') 来获取GET参数，而不是去form或json里找——那是处理POST请求的路径。
拿到关键词后，有两件事必须立刻做：一是过滤空值，二是基础清洗。为什么？因为一个空的搜索词会导致 LIKE '%%' 这样的查询，其结果就是数据库进行全表扫描，性能杀手。而清洗首尾空格，则是为了避免用户输入了 " flask " 却匹配不到数据库里的 "flask"，.strip() 方法在这里就派上用场了。
- 空值检查是底线：永远判断
q是否为空或仅含空白符。如果是，应该跳过数据库查询，直接返回空结果或提示。 - 远离字符串拼接：即使在路由层，也不建议直接拼接SQL字符串。安全的做法是将参数化查询的逻辑交给下一层——也就是ORM。
- 编码交给框架：如果前端对关键词进行了
encodeURIComponent编码，Flask的请求对象会自动解码，无需手动处理。
Flask中接收搜索关键词应使用request.args.get('q', '')获取GET参数，需过滤空值并调用.strip()清洗空白符；SQLAlchemy中须用ilike(f'%{q}%')等参数化方式实现安全LIKE查询，禁用字符串拼接以防SQL注入。
SQLAlchemy 中怎么安全写 LIKE 查询
这里是安全的重灾区。核心原则就一条：绝对不要用Python的字符串操作（比如 % 格式化或 +）来拼接SQL语句。像 WHERE name LIKE '%{q}%' 这样的写法，无异于为SQL注入攻击敞开了大门。
正确的姿势，是把通配符和用户输入的值分开处理，让SQLAlchemy通过参数化查询来确保安全。推荐使用 ilike 方法（在PostgreSQL中支持），它忽略大小写，写法简洁：
立即学习“Python免费学习笔记（深入）”；
db.session.query(User).filter(User.name.ilike(f'%{q}%'))
如果需要执行原生SQL语句（例如使用 text()），则必须使用命名参数来传递值：
db.session.execute(text("SELECT * FROM user WHERE name LIKE :pattern"), {"pattern": f"%{q}%"})
ilike的优势：它通常比手动使用lower(name) LIKE lower(:q)更高效，因为数据库引擎可能对其进行优化。- SQLite的注意事项：SQLite默认不支持
ilike，需要显式指定排序规则，如User.name.like(f'%{q}%', escape='\\')。 - 转义通配符：如果用户输入中可能包含
%、_这些SQL通配符，或者反斜杠转义符，务必使用escape参数来防止意外匹配。例如，设置escape='\\'并预先处理输入中的反斜杠。
为什么搜索结果分页不能用 OFFSET LIMIT 做深分页
分页是搜索体验的关键一环，但方法用错了，性能就会急剧下降。经典的 OFFSET LIMIT 分页在深分页时（比如用户翻到第100页）问题凸显：数据库必须先扫描并跳过前990条记录，然后才返回第100页的10条。当数据量大或查询本身较慢时，这种“先读后弃”的开销是巨大的。
对于初期项目，使用Flask-SQLAlchemy的 paginate 方法可以快速实现分页，但要知道它的底层依然是 OFFSET：
users = User.query.filter(User.name.ilike(f'%{q}%')).paginate(page=page, per_page=10)
- 适用场景：数据量小、分页深度浅的情况下，
paginate完全够用。 - 性能警报：一旦发现翻页到后面（例如超过50页）响应延迟明显增加（比如超过500ms），就需要考虑切换到游标分页（或称“键集分页”），即基于上一页最后一条记录的ID或时间戳进行查询。
- 避免组合拳：不要在模糊查询的结果上轻易添加复杂的排序（如
ORDER BY id DESC）再进行深分页，除非排序字段有索引，否则会雪上加霜。
搜索字段没索引会导致全表扫描
这是另一个常见的性能瓶颈。即使你的表只有1000行，一个 LIKE '%python%' 查询（中缀匹配）也足以让大多数数据库的B-tree索引失效，从而退回到全表扫描。只有 LIKE 'python%'（前缀匹配）才能有效利用索引。
如果业务确实需要支持中缀或更灵活的搜索，那么是时候考虑更专业的工具了：
- PostgreSQL：为字段创建
GIN索引，并使用to_tsvector和to_tsquery进行全文检索，速度比LIKE快得多。 - SQLite：可以创建
FULLTEXT虚拟表，使用MATCH操作符进行搜索。 - MySQL：使用
FULLTEXT索引和MATCH ... AGAINST语法。对于中文，可能需要安装ngram分词插件。 - 最后的手段：对于极小的、静态的数据集，可以尝试在Python内存中进行过滤（例如列表推导式）。但切记，这只适用于数据量极小且不常变化的场景，切勿用于生产环境的大数据量查询。
说到底，实现一个模糊搜索功能，难点往往不在Flask应用层，而在数据库层。从关键词的安全接收到通配符的正确使用，从分页策略的选择到索引的合理设计，环环相扣。忽略任何一环，都可能导致用户一个简单的搜索请求，就要等待令人沮丧的数秒。把这些细节处理好，搜索体验才能流畅自如。
