先说说环境搭建。我用的MySQL 8.0，GraphQL服务端选的是Apollo Server，中间用Prisma做ORM连接层。这里有个坑要注意：Prisma的版本一定要和GraphQL的适配器版本对应，不然各种诡异报错能让人崩溃。我在dependency里折腾了整整一天，最后锁定在prisma@4.12和@apollo/server@4.7这个组合才跑通。
核心配置其实就三大块。首先是数据库连接，在prisma/schema.prisma里定义datasource，这个比较简单。重点是数据模型定义，比如用户表这么写：
接着要定义GraphQL的schema，这里我用了SDL方式。特别注意类型匹配问题，MySQL的DATETIME对应GraphQL的String，Boolean对应MySQL的TINYINT(1)。最开始没注意这个，直接定义的Boolean类型死活读不出数据。
查询接口的实现最有意思。原来RESTful接口要写十几个端点，现在一个Query类型就搞定了：
解析器里用PrismaClient操作数据库，比原生SQL简洁多了。不过这里遇到个性能坑：当查询嵌套关系时，比如同时要用户和他的文章列表，容易产生N+1查询问题。后来用了Prisma自带的include参数才解决，这个后面详细说。
实战中做了个博客系统的案例。用户表、文章表、评论表三张表，原来需要/user/:id、/posts?userId=1、/comments?postId=1三个接口，现在前端只要发一个查询：
后端响应速度从原来的300ms降到了80ms，因为减少了两次HTTP往返。但这里要注意：虽然HTTP请求少了，数据库压力可能会增加，一定要做好索引优化。我在posts表的userId字段和comments表的postId字段都加了复合索引。
权限控制这块也花了些心思。GraphQL可以通过指令系统实现字段级权限，比如把手机号字段设置成只有管理员能查询：
相比RESTful要在每个接口里写权限判断代码，这样确实优雅不少。
最后说说踩坑记录。最大的坑是分页查询，GraphQL的游标分页和MySQL的LIMIT分页概念不太一样。后来折中采用了基于页码的分页方案，在resolve函数里转换参数。还有缓存问题，GraphQL的单个端点特性让传统的HTTP缓存失效，只能靠应用层缓存弥补。
部署时也遇到个坑：Prisma在生产环境需要单独生成客户端，记得在package.json的postinstall钩子里加上prisma generate命令。
折腾下来总体是值得的。虽然学习曲线有点陡，但后期开发效率提升明显。特别是对于业务复杂的项目，前端可以自由组合查询字段，后端接口维护量大幅减少。不过如果项目很简单，或者团队对GraphQL不熟悉，建议还是慎用，毕竟解决问题的同时也会带来新的复杂度。
现在我这套方案已经在测试环境跑通了，正准备往生产环境迁移。有同样需求的朋友可以参考这个思路，但具体实现还是要根据业务场景调整。下次准备试试把GraphQL订阅功能加进来，实现实时数据推送，到时候再和大家分享经验。