PHP laravel SQL优化

布满荆棘的人生 2022-06-01 02:14 302阅读 0赞

# SQL优化的态度 #

\--Facebook做产品的时候，注重一句话，我们不求完美，我们先把产品运行起来！

其实上边的话，我也是对自己的说的，最近比较忙，闲暇时光，总结一下过去的薄弱点，不论你做什么，写什么，你总会遇到困难，总会遇到挫折，那个时候才是你真正提高的时候，绝对......是这样，当你重复做一些事情的时候，你会慢慢厌烦，慢慢的感到不满，也许你可以认为我说的不对，但是我有必要告诉你，也有必要警醒我自己，理当磨炼，敢为天下先。

回归今天的主题：

keyword：SQL优化、态度

然而你又说了，优化谁不会呢，但是态度呢？也许就不见得了，各说纷纭，争先恐后？？？

我今天想要表达的很简单，你对SQL优化的态度是真诚的吗？现在都说项目经验，能不能独立完成项目，靠的是什么，靠的是你是否有信心，有能力，独立扛起你不懂但是通过你对努力，你能够解决的问题，这是担当，随着你工作、能力的提高，你会觉得，你的压力和你的薪资都会更大，那是我们成长了不少，我们对待事情的态度发生了改变，思想改变了，我们也就变了。

回归正题：对于laravel transformer结构的优化

之前的做法和想法，为提供前后台分离，我们提供接口，在架构的基础上，我们用一个后台做接口，尽量在使用同一个transformer的基础上，尽可能的复用、复用，自己写的代码是简单了，for example：

Route::get('packages/\{id\}','Api\\PackageController@show');

//路由，写一个套餐接口

public function show($id)  
    \{  
  
  
        $packages = $this->packageService->with(includes())->findByPackageId($id);  
           
        if (!$packages) \{  
            return error(\\Msg::PACKAGE\_NOT\_FOUND);  
        \}  
  
  
        $results = fractal($packages, new PackageTransformer())  
            ->parseIncludes(includes())  
            ->toArray();  
  
  
        return $this->response($results);  
    \}

//我们使用了service做服务层、repository做仓库，分页结果给fractal进行解析，使用include来添加关联的一系列

套餐相关的课程

<?php  
  
  
namespace App\\Transformers;  
use League\\Fractal\\TransformerAbstract;  
use App\\Models\\Package;  
  
class PackageTransformer extends TransformerAbstract  
\{  
    /\*\*  
     \* A Fractal transformer.  
     \*  
     \* @return array  
     \*/  
    protected $availableIncludes = \[  
        'courses',  
    \];  
  
  
    public function transform(Package $package)  
    \{  
        $all =  \[  
            'id'                 => $package->id,  
            'name'               => $package->name,  
            'category'           => empty($package->category\['name'\]) ? 0 : $package->category\['name'\],  
            'type'               => $package->type,  
            'short\_introduction' => $package->short\_introduction,  
            'detail'             => $package->detail,  
            'price'              => $package->prices(),  
            'discount\_price'     => $package->discount\_price,  
            'learning\_number'    => $package->number+ $package->base\_number  
        \];  
          
  
    \}  
    public function includeCourses(Package $package)  
    \{  
        return $this->collection($package->courses,new CourseTransformer());  
    \}  
  
\}

//上边就是include的使用include=courses这种参数关联的方式，耦合套餐，也许套餐关联课程结构的时候也许不需要

这个事情，之前就没有考虑到。

然后我们考虑一件事情：性能（之前听一个学者说，使用了laravel就抛弃了性能，给我造成了心理上不可磨灭的阴影，现在对我来说，都是他妈的扯淡），SQL优化

先从优化开始，先说件重要的事情：不论你是什么后台语言开发者，JAVA，PHP还是其他，必备的工具，能够可视化看到你的sql语句的调试工具，DEBUG模式一定要开启，TEST类一定要写，特别是接口测试，对于接口多的时候，你就知道好处了，你花费写接口测试是为了节省你的事情做最重要的事情，我现在使用postman总是调试接口的时候对于参数特别的时候，一个一个添加是多么无知的。

![Center][]

你可以看看，写了多少无知的SQL，一个接口造成性能堪忧，归根结底就是这个接口的代码写的太烂，烂到令人发指，归纳，总结牛逼之人总有牛逼之人之处，做半天工作，能够使你做三天，然后时候给你讲解时候，他倒是觉得也没有那么难，就是过程不容易直接想到，都是通过一步步优化造成的结果，你也可以。

优化之前：

$unitTestPaper = \\App\\Models\\TestPaper::where('unit\_id',$this->id)->first();

优化之后：

$unitTestPaper = $this->testPapers->first();

下面造成关联试卷为空的操作优化后和优化之前，多查询了一百条sql，感觉有罪恶感啊，瞬间变为了

![Center 1][]

这就是差别，然后又开始分析，由于套餐下面有阶段，tag，阶段用with直接关联课程，所以并没有使用include，造成大量的sql涌入

public function findByPackageId($id)  
    \{  
  
  
        $package = $this->model->where('id',$id)->first();  
  
  
        $package->tags->load(\['courses' => function($query) use ($id) \{  
            $query->where('package\_id',$id);  
        \},'courses.teachers','courses.listImage','courses.periods.chapters.units.testPapers'\]);  
  
  
        // $package->tags->map(function($tag)\{  
        //      return $tag->courses;  
        // \})->flatten()->load('teachers');  
  
  
        return $package;  
    \}

直接把'courses.teachers','courses.listImage','courses.periods.chapters.units.testPapers'加入查询一次就ok。必须要对其进行sql处理

![Center 2][]

经过最后的优化，只剩下了28条，其实还可以去除还有一些重复，基本上不会太大影响性能了，比之前快了不止一个档次，之前，从后台得到的数据都很慢，经过优化，速度提上去了

最后我在告诉你们一点：先完成功能，完成功能之前先思考，然后才是在有能力，有时间的情况下，尽早优化，不要推迟，一推迟，你就不想做了，记得我说的话

\--时刻警醒自己

转自:[http://blog.csdn.net/chajinglong/article/details/76401057][http_blog.csdn.net_chajinglong_article_details_76401057]

[Center]: /images/20220601/2fa77f60b8bc4c12bc5262559d064f5f.png
[Center 1]: /images/20220601/c6da65cbf0cd451aa179458caeb7119f.png
[Center 2]: /images/20220601/1af38cd27ff540b0a4592c4c8c93e045.png
[http_blog.csdn.net_chajinglong_article_details_76401057]: http://blog.csdn.net/chajinglong/article/details/76401057