mysql innodb

[pchayka]

Механизм у них не менялся, все те же процедуры, все та же структура серверная. Использовать процедуры не так удобно в mysql, как в mssql, но было бы интересно посмотреть на практическую реализацию этого ибо

Код:

st.set(1, var1);
st.set(2, var2);
st.set(1, var1);
st.set(2, var2);
st.set(1, var1);
st.set(2, var2);

всегда раздражал.

Добавлено через 1 минуту

Ну если ты помнишь Ему Ент Визор довольно часто держал разные части кода на процедурах и да , довольно удачно.

когда я использовал ему рт для сервера лагало на моих 300 онлайна при 100 человеках в локе так жутко, что было сугубо однофигственно что там используется...

[Deazer]

Механизм у них не менялся, все те же процедуры, все та же структура серверная. Использовать процедуры не так удобно в mysql, как в mssql, но было бы интересно посмотреть на практическую реализацию этого ибо

Код:

st.set(1, var1);
st.set(2, var2);
st.set(1, var1);
st.set(2, var2);
st.set(1, var1);
st.set(2, var2);

всегда раздражал.

да но используется довольно редко , сабы , кланы (некоторые части). В айтемах скажем , такого и близко нет.
Практическая MySql реализация хранимок ничем примечательным не отличается от Т sql , только особенности MySQL

Код

MySQL

PHP код:

<?php 

CREATE PROCEDURE `lip_LoadItemsByOwnerAndLoc` (IN iOwnerID INTEGER UNSIGNED, 

            IN eLoc ENUM('VOID','INVENTORY','PAPERDOLL','WAREHOUSE','FREIGHT','CLANWH','MAIL','PET_INVENTORY','PET_PAPERDOLL'))

 NOT DETERMINISTIC

 SQL SECURITY DEFINER

BEGIN

  SELECT SQL_NO_CACHE 

    `i`.`item_id` AS `item_id`,

    `i`.`owner_id` AS `owner_id`,

    `i`.`item_type` AS `item_type`,

    `i`.`amount` AS `amount`,

    `i`.`location` AS `location`,

    `i`.`slot` AS `slot`,

    `i`.`enchant` AS `enchant`,

    IFNULL(`id`.`duration`, -9999) AS `duration`,

    IFNULL(`ip`.`period`, -1) AS `period`,

    IFNULL(`ia`.`attack_type`, -2) AS `attack_attr_type`,

    IFNULL(`ia`.`attack_value`, 0) AS `attack_attr_val`,

    IFNULL(`ia`.`defence_fire`, 0) AS `defence_attr_fire`,

    IFNULL(`ia`.`defence_water`, 0) AS `defence_attr_water`,

    IFNULL(`ia`.`defence_wind`, 0) AS `defence_attr_wind`,

    IFNULL(`ia`.`defence_earth`, 0) AS `defence_attr_earth`,

    IFNULL(`ia`.`defence_holy`, 0) AS `defence_attr_holy`,

    IFNULL(`iv`.`stat1`, 0) AS `variation_stat1`,

    IFNULL(`iv`.`stat2`, 0) AS `variation_stat2`,

    IFNULL(`io`.`blessed`, 0) AS `blessed`,

    IFNULL(`io`.`damaged`, 0) AS `damaged`,

    IFNULL(`io`.`energy`, 0) AS `item_energy`,

    IFNULL(`io`.`flags`, 0) AS `custom_flags`

  FROM

    `items` `i`

    LEFT JOIN 

      `items_duration` `id`

    ON

      `id`.`item_id` = `i`.`item_id` -- iItemID

    LEFT JOIN

      `items_period` `ip`

    ON

      `ip`.`item_id` = `i`.`item_id` -- iItemID

    LEFT JOIN

      `items_attributes` `ia`

    ON

      `ia`.`item_id` = `i`.`item_id` -- iItemID

    LEFT JOIN

      `items_variation` `iv`

    ON

      `iv`.`item_id` = `i`.`item_id` -- iItemID

    LEFT JOIN

      `items_options` `io`

    ON

      `io`.`item_id` = `i`.`item_id` -- iItemID

  WHERE `i`.`owner_id` = iOwnerID AND `i`.`location` = eLoc;

END $$ 

TSql

PHP код:

<?php 

SELECT

    ui.item_id, ui.item_type, ui.amount, ui.enchant, ui.eroded, ui.bless, ui.ident, ui.wished,

    isnull(ui.variation_opt1, 0),

    isnull(ui.variation_opt2, 0),

    isnull(ui.intensive_item_type, 0),

    isnull(ui.inventory_slot_index, -1),

    isnull(uia.attack_attribute_type, -2),

    isnull(uia.attack_attribute_value, 0),

    isnull(uia.defend_attribute_0, 0),

    isnull(uia.defend_attribute_1, 0),

    isnull(uia.defend_attribute_2, 0),

    isnull(uia.defend_attribute_3, 0),

    isnull(uia.defend_attribute_4, 0),

    isnull(uia.defend_attribute_5, 0)

FROM (select * from user_item(nolock) where char_id = @char_id and warehouse = @warehouse) ui

    left join user_item_attribute uia(nolock) on ui.item_id = uia.item_id

WHERE item_type > 0 

[GameMems]

раз в несколько минут через mytop в логе появляются запросы в items типа етого:
217 root localhost:54695 l2jdb3 12 Query UPDATE items SET owner_id=268480986,count=1,loc='INVENTORY',loc_data=0,enchant_level=0,price_sell=0,price_buy=0,custom_type1=0,custom_type2=0,mana_left=-1 WHERE object_id =

и во время етого появляется лаг на 5-10 секунд... обновил mysql-connector до 5.1.16, до етого стоял 5.1.6 - не помогло

[Visor]

Те что были дописаны - то сервисные процедуры, типа сделать вайп, вытянуть что-то, зачистить чара - они так и есть в поставке, но сам л2 сервер их не использует, да и нету надобности - в направлении работы с базой данных нет нагрузки - я еще давно выкинул бибку-пул неудачный и повыравнивал код.

По теме - если у автора есть проблемы с myisam таблицами - то вероятнее всего это какой-то вид блокировок включен в настройках - надо выключать, ну и как я писал надо обновить бибку коннектора - и будет бегать и не нужно сначала пыжится ставить на иннодб, а потом бороться с иннодб опять же с отсутствием знание как настраивается этот движок.

[pchayka]

Простейший запрос с поиском по конкретному ключу, как это может лагать...

интересно что вот это вообще делает в той таблице...

price_sell=0,price_buy=0,custo m_type1=0,custom_type2=0

[Visor]

раз в несколько минут через mytop в логе появляются запросы в items типа етого:
217 root localhost:54695 l2jdb3 12 Query UPDATE items SET owner_id=268480986,count=1,loc='INVENTORY',loc_data=0,enchant_level=0,price_sell=0,price_buy=0,custom_type1=0,custom_type2=0,mana_left=-1 WHERE object_id =

и во время етого появляется лаг на 5-10 секунд... обновил mysql-connector до 5.1.16, до етого стоял 5.1.6 - не помогло

insert/replace/update блокируют для myisam всю таблицу, и это не выключается - потому что так им надо.

для этого запроса нужен только 1 индекс - примари на object_id
Но вот зачем обновляется овнер непонятно (разве что ссмена владельца). Есть мысль что есть еще запросы - которые не могут использовать те индексы что есть на таблице - они и будут давать задержки.

[hex1r0]

раз в несколько минут через mytop в логе появляются запросы в items типа етого:
217 root localhost:54695 l2jdb3 12 Query UPDATE items SET owner_id=268480986,count=1,loc='INVENTORY',loc_data=0,enchant_level=0,price_sell=0,price_buy=0,custom_type1=0,custom_type2=0,mana_left=-1 WHERE object_id =

не полный лог

2Deazer, 2Visor, innodb row locking тоже может сыграть свою роль, потом теоретически флуш на хард в инннодб может быть выше насчет особенности хранения, потом, опять таки foreign-keys


2GameMems убедись что в коде сейва инвентаря есть клоузы конекшинов и стейтментов

[Deazer]

не полный лог

2Deazer, 2Visor, innodb row locking тоже может сыграть свою роль, потом теоретически флуш на хард в инннодб может быть выше насчет особенности хранения, потом, опять таки foreign-keys


2GameMems убедись что в коде сейва инвентаря есть клоузы конекшинов и стейтментов

Тейбл локинг выгодней и быстрее в данных задачах

[Visor]

не полный лог

2Deazer, 2Visor, innodb row locking тоже может сыграть свою роль, потом теоретически флуш на хард в инннодб может быть выше насчет особенности хранения, потом, опять таки foreign-keys

Это на форуме в посте кажется тру идеей, но на практике не все так как хочется. Запросы меняющие поле с ключем заблокируют заблицу на момент выполнения, точнее индекс - что для конечного пользователя будет выглядеть как блокировка таблицы.
К чему приплетать внешние ключи - не совем понятно. Для запросов они ни на что не влияют и не являются индексами, которые использует анализатор и исполнитель в mysql.

Добавлено через 1 минуту
Для автора - посидите немного помотрите processlist - запросы длинее чем 200-300мс это уже нужно брать запрос и проверять как его выполняет mysql

[Deazer]

:redlol: а вообще почти на 100% уверен что афтор держит и сайт с форумом на одном сервере и т.д. при этом имеет на борту не достаточно ресурсов.

Добавлено через 34 секунды
То что ты скинул - следствие , а не проблема