Запросы mysql API Laravel не отслеживаются в performance_schema.events_statements_summary_by_digest

avatar
Ankit
8 апреля 2018 в 04:20
424
1
10

Я столкнулся с очень странной проблемой. У нас есть laravel API, размещенный на AWS EC2, и мы используем RDS (mysql 5.6). Недавно я включил performance_schema в RDS. Ниже приведено поведение, которое я заметил

.
  1. На нашем экземпляре RDS есть две базы данных. Один для wordpress и один для нашего laravel API. Запрос к базе данных Wordpress обрабатывается нормально. Но запросы, выполняемые из нашего приложения laravel, — нет.
  2. По какой-то причине, когда я подключаю MySql Workbench к экземпляру RDS и выполняю запросы в нашей базе данных Laravel, они отображаются в сводке операторов в порядке.
  3. Я вошел в свою машину EC2, подключился к MySQL через RDS и выполнил несколько запросов, и они отслеживаются в сводке выписки.

Похоже, что только когда запросы выполняются из нашего приложения Laravel, они не отслеживаются.

Наша версия Laravel — 4.2. Я пытаюсь определить причину последних двух дней, любая помощь будет облегчением.

Пользователь, которого я использовал во всех предыдущих шагах, один и тот же и имеет все привилегии во всех базах данных.

-- РЕДАКТИРОВАТЬ --

Я провел много других тестов, и все они указывают только на один вывод, что это как-то связано с Laravel. Я создал простой файл php на том же сервере, где размещен laravel. В этом файле я подключился к тому же экземпляру/базе данных с тем же пользователем/паролем. Единственное, что я сделал в этом файле, это запустил очень простой запрос к $pdo, подобный этому.

$stmt = $pdo->query('SELECT name FROM trades');
        while ($row = $stmt->fetch())
        {
            echo $row['name'] . "\n";
        }

и он отображается в аналитике запросов [https://prnt.sc/j3ochd] (я также вручную проверил performance_schema.events_statements_summary_by_digest)

Но затем я могу запустить наш laravel API, который на самом деле возвращает записи из самой торговой таблицы (очень похоже на запрос, который я запускаю выше). но это будет отображаться в моих аналитических отчетах по запросам (Percona PMM) или в events_statements_summary_by_digest

Источник

Ответы (1)

avatar
Vikash Pathak
12 апреля 2018 в 09:05
9

Вы должны передать параметр options в базу данных> настройки подключения как PDO::ATTR_EMULATE_PREPARES => true

config > database.php

'connections' => [

    'mysql' => [
        'driver' => 'mysql',
        'host' => env('DB_HOST', '127.0.0.1'),
        'port' => env('DB_PORT', '3306'),
        'database' => env('DB_DATABASE', 'forge'),
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
        'unix_socket' => env('DB_SOCKET', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => '',
        'strict' => false,
        'engine' => null,
        'options' => [
            PDO::ATTR_EMULATE_PREPARES => true
        ]
    ],

]

По умолчанию laravel помечает эти параметры как PDO::ATTR_EMULATE_PREPARES => false для повышения производительности запросов.

Вот краткие подробности об этом.

PDO::ATTR_EMULATE_PREPARES Включает или отключает эмуляцию подготовленных операторов. Некоторые драйверы не поддерживают собственные подготовленные операторы или имеют ограниченную поддержку. Используйте этот параметр, чтобы заставить PDO либо всегда эмулировать подготовленные инструкции (если TRUE и эмулированные подготовки поддерживаются драйвером), либо пытаться использовать собственные подготовленные инструкции (если FALSE). Он всегда будет возвращаться к эмуляции подготовленного оператора, если драйвер не может успешно подготовить текущий запрос.

Rick James
12 апреля 2018 в 13:24
0

Я озадачен тем, насколько важна «подготовка». Независимо от того, подготовлено оно или нет, "SELECT ..." в конечном итоге отправляется на сервер, после чего сервер записывает его по запросу.

Ankit
13 апреля 2018 в 06:38
0

@RickJames Я сбит с толку, но кажется, что Викаш прав. После внесения этого запроса на изменение, кажется, что он начинает появляться в дайджесте. [bugs.mysql.com/bug.php?id=80173], похоже, тоже самое.

Ankit
13 апреля 2018 в 06:41
0

есть официальный ответ: «после сравнения текущего поведения инструментирования подготовленных операторов из приглашения SQL и из C API мы выяснили, что в обоих этих случаях инструментирование фактического запроса, используемого в подготовленном операторе, не выполняется»

Ankit
13 апреля 2018 в 06:43
0

@vikash-pathak Я где-то читал, что если я сделаю это изменение, все поля будут возвращены в виде строки. Немного беспокоюсь, может ли это как-то сломать наше существующее приложение. Но для вопроса, который у меня был, ваши решения, похоже, работают. Итак, принимая