chukcha Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product` ( `product_id` int(11) NOT NULL AUTO_INCREMENT, `model` varchar(64) NOT NULL, `sku` varchar(64) NOT NULL, `upc` varchar(12) NOT NULL, `ean` varchar(14) NOT NULL, `jan` varchar(13) NOT NULL, `isbn` varchar(13) NOT NULL, `mpn` varchar(64) NOT NULL, `location` varchar(128) NOT NULL, `quantity` int(4) NOT NULL DEFAULT '0', `stock_status_id` int(11) NOT NULL, `image` varchar(255) DEFAULT NULL, `manufacturer_id` int(11) NOT NULL, `shipping` tinyint(1) NOT NULL DEFAULT '1', `price` decimal(15,4) NOT NULL DEFAULT '0.0000', `points` int(8) NOT NULL DEFAULT '0', `tax_class_id` int(11) NOT NULL, `date_available` date NOT NULL, `weight` decimal(15,8) NOT NULL DEFAULT '0.00000000', `weight_class_id` int(11) NOT NULL DEFAULT '0', `length` decimal(15,8) NOT NULL DEFAULT '0.00000000', `width` decimal(15,8) NOT NULL DEFAULT '0.00000000', `height` decimal(15,8) NOT NULL DEFAULT '0.00000000', `length_class_id` int(11) NOT NULL DEFAULT '0', `subtract` tinyint(1) NOT NULL DEFAULT '1', `minimum` int(11) NOT NULL DEFAULT '1', `sort_order` int(11) NOT NULL DEFAULT '0', `status` tinyint(1) NOT NULL DEFAULT '0', `date_added` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `date_modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `viewed` int(5) NOT NULL DEFAULT '0', `asticker_id` int(11) NOT NULL DEFAULT '0', `asticker_date_start` date NOT NULL DEFAULT '0000-00-00', `asticker_date_end` date NOT NULL DEFAULT '0000-00-00', PRIMARY KEY (`product_id`), UNIQUE KEY `product_id` (`product_id`), UNIQUE KEY `product_id_2` (`product_id`), KEY `model` (`model`), KEY `stock_status_id` (`stock_status_id`), KEY `manufacturer_id` (`manufacturer_id`), KEY `tax_class_id` (`tax_class_id`), KEY `weight_class_id` (`weight_class_id`), KEY `length_class_id` (`length_class_id`), KEY `asticker_id` (`asticker_id`), KEY `model_2` (`model`), KEY `sku` (`sku`), KEY `upc` (`upc`), KEY `manufacturer_id_2` (`manufacturer_id`), KEY `sort_order` (`sort_order`), KEY `status` (`status`), KEY `date_available` (`date_available`), KEY `model_3` (`model`), KEY `sku_2` (`sku`), KEY `upc_2` (`upc`), KEY `manufacturer_id_3` (`manufacturer_id`), KEY `sort_order_2` (`sort_order`), KEY `status_2` (`status`), KEY `date_available_2` (`date_available`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=538 ; Пользуйтесь советами псевдооптимизаторов добавляйте индексы, и конвертируйте в InnoDb CREATE TABLE IF NOT EXISTS `oc_order` ( `order_id` int(11) NOT NULL AUTO_INCREMENT, `invoice_no` int(11) NOT NULL DEFAULT '0', `invoice_prefix` varchar(26) NOT NULL, `store_id` int(11) NOT NULL DEFAULT '0', `store_name` varchar(64) NOT NULL, `store_url` varchar(255) NOT NULL, `customer_id` int(11) NOT NULL DEFAULT '0', `customer_group_id` int(11) NOT NULL DEFAULT '0', `firstname` varchar(32) NOT NULL, `lastname` varchar(32) NOT NULL, `email` varchar(96) NOT NULL, `telephone` varchar(32) NOT NULL, `fax` varchar(32) NOT NULL, `payment_firstname` varchar(32) NOT NULL, `payment_lastname` varchar(32) NOT NULL, `payment_company` varchar(32) NOT NULL, `payment_company_id` varchar(32) NOT NULL, `payment_tax_id` varchar(32) NOT NULL, `payment_address_1` varchar(128) NOT NULL, `payment_address_2` varchar(128) NOT NULL, `payment_city` varchar(128) NOT NULL, `payment_postcode` varchar(10) NOT NULL, `payment_country` varchar(128) NOT NULL, `payment_country_id` int(11) NOT NULL, `payment_zone` varchar(128) NOT NULL, `payment_zone_id` int(11) NOT NULL, `payment_address_format` text NOT NULL, `payment_method` varchar(128) NOT NULL, `payment_code` varchar(128) NOT NULL, `shipping_firstname` varchar(32) NOT NULL, `shipping_lastname` varchar(32) NOT NULL, `shipping_company` varchar(32) NOT NULL, `shipping_address_1` varchar(128) NOT NULL, `shipping_address_2` varchar(128) NOT NULL, `shipping_city` varchar(128) NOT NULL, `shipping_postcode` varchar(10) NOT NULL, `shipping_country` varchar(128) NOT NULL, `shipping_country_id` int(11) NOT NULL, `shipping_zone` varchar(128) NOT NULL, `shipping_zone_id` int(11) NOT NULL, `shipping_address_format` text NOT NULL, `shipping_method` varchar(128) NOT NULL, `shipping_code` varchar(128) NOT NULL, `comment` text NOT NULL, `total` decimal(15,4) NOT NULL DEFAULT '0.0000', `order_status_id` int(11) NOT NULL DEFAULT '0', `affiliate_id` int(11) NOT NULL, `commission` decimal(15,4) NOT NULL, `language_id` int(11) NOT NULL, `currency_id` int(11) NOT NULL, `currency_code` varchar(3) NOT NULL, `currency_value` decimal(15,8) NOT NULL DEFAULT '1.00000000', `ip` varchar(40) NOT NULL, `forwarded_ip` varchar(40) NOT NULL, `user_agent` varchar(255) NOT NULL, `accept_language` varchar(255) NOT NULL, `date_added` datetime NOT NULL, `date_modified` datetime NOT NULL, PRIMARY KEY (`order_id`), KEY `order_status_id` (`order_status_id`), KEY `customer_id` (`customer_id`), KEY `store_id` (`store_id`), KEY `customer_group_id` (`customer_group_id`), KEY `payment_company_id` (`payment_company_id`), KEY `payment_tax_id` (`payment_tax_id`), KEY `payment_country_id` (`payment_country_id`), KEY `payment_zone_id` (`payment_zone_id`), KEY `shipping_country_id` (`shipping_country_id`), KEY `shipping_zone_id` (`shipping_zone_id`), KEY `affiliate_id` (`affiliate_id`), KEY `language_id` (`language_id`), KEY `currency_id` (`currency_id`), KEY `customer_id_2` (`customer_id`), KEY `customer_id_3` (`customer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=68 ; магазин грузится 17 сек!!! CREATE TABLE IF NOT EXISTS `oc_category` ( `category_id` int(11) NOT NULL AUTO_INCREMENT, `image` varchar(255) DEFAULT NULL, `parent_id` int(11) NOT NULL DEFAULT '0', `top` tinyint(1) NOT NULL, `column` int(3) NOT NULL, `sort_order` int(3) NOT NULL DEFAULT '0', `status` tinyint(1) NOT NULL, `date_added` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', `date_modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', PRIMARY KEY (`category_id`), KEY `parent_id` (`parent_id`), KEY `parent_id_2` (`parent_id`), KEY `top` (`top`), KEY `sort_order` (`sort_order`), KEY `status` (`status`), KEY `parent_id_3` (`parent_id`), KEY `top_2` (`top`), KEY `sort_order_2` (`sort_order`), KEY `status_2` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=83 ; Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 @buslikdrev я промолчу.. Хорошо? А то рука очень медленно потянулась влепить минус. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 @chukcha а в чем возмущение то? у innodb немного другое назначение, и без надобности использовать смысла нет. С другой стороны в архитектуре магазина эта надобность всегда есть а для быстрых селектов строятся flat таблицы Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Какая надобность при указанных данных А на количество индексов смотрели.. Дело не в том что они дублируются, дело в том что оно есть без надобности. Надіслати Поділитися на інших сайтах More sharing options... snastik Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 10 минут назад, magecode сказал: С другой стороны в архитектуре магазина эта надобность всегда есть Назовите мне надобность на более менее статическую (чтение) таблицу oc_product для oc_cart которая является наиболее востребуемой динамически, и куда происходит часто запись/чтение я ничего не сказал. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 @buslikdrev я промолчу.. Хорошо? А то рука очень медленно потянулась влепить минус. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 @chukcha а в чем возмущение то? у innodb немного другое назначение, и без надобности использовать смысла нет. С другой стороны в архитектуре магазина эта надобность всегда есть а для быстрых селектов строятся flat таблицы Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Какая надобность при указанных данных А на количество индексов смотрели.. Дело не в том что они дублируются, дело в том что оно есть без надобности. Надіслати Поділитися на інших сайтах More sharing options... snastik Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 10 минут назад, magecode сказал: С другой стороны в архитектуре магазина эта надобность всегда есть Назовите мне надобность на более менее статическую (чтение) таблицу oc_product для oc_cart которая является наиболее востребуемой динамически, и куда происходит часто запись/чтение я ничего не сказал. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 @chukcha а в чем возмущение то? у innodb немного другое назначение, и без надобности использовать смысла нет. С другой стороны в архитектуре магазина эта надобность всегда есть а для быстрых селектов строятся flat таблицы Надіслати Поділитися на інших сайтах More sharing options...
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Какая надобность при указанных данных А на количество индексов смотрели.. Дело не в том что они дублируются, дело в том что оно есть без надобности. Надіслати Поділитися на інших сайтах More sharing options... snastik Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 10 минут назад, magecode сказал: С другой стороны в архитектуре магазина эта надобность всегда есть Назовите мне надобность на более менее статическую (чтение) таблицу oc_product для oc_cart которая является наиболее востребуемой динамически, и куда происходит часто запись/чтение я ничего не сказал. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
snastik Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 10 минут назад, magecode сказал: С другой стороны в архитектуре магазина эта надобность всегда есть Назовите мне надобность на более менее статическую (чтение) таблицу oc_product для oc_cart которая является наиболее востребуемой динамически, и куда происходит часто запись/чтение я ничего не сказал. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 10 минут назад, magecode сказал: С другой стороны в архитектуре магазина эта надобность всегда есть Назовите мне надобность на более менее статическую (чтение) таблицу oc_product для oc_cart которая является наиболее востребуемой динамически, и куда происходит часто запись/чтение я ничего не сказал. Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 Только что, snastik сказал: в каком месте дублированные индексы на 500 товарах дают 17 секунд? А также с чего это вдруг innodb без mariadb 10? А fulltext куда деть ?/ По моему вы тут слепили немного горбатого. Это не я!!!! Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 (змінено) 1 hour ago, chukcha said: А на количество индексов смотрели.. Об индексах я ничего не говорил, там и так понятно что фантастика 55 minutes ago, chukcha said: Назовите мне надобность на более менее статическую (чтение) таблицу oc_product не об этом речь, конкретно для одной таблицы толку никакого, а в oc_cart наверное предполагалось использовать для связки ключей (которой нет) 55 minutes ago, snastik said: А fulltext куда деть ? да никуда, для fulltext'a просто оставляют таблицы в myisam. @chukcha а что это за псевдооптимизаторы, на которые вы так возмущены? Змінено 16 серпня 2017 користувачем magecode Надіслати Поділитися на інших сайтах More sharing options...
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 мне сбросили дамп.. мол посмотри. Посмотрел. Отсюда и пост Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options... chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV × Уже зареєстровані? Ввійти Реєстрація Ваші замовлення Назад Придбані модулі та шаблони Ваші рахунки Лист очікувань Альтернативні контакти Форум Новини ocStore Назад Офіційний сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Завантажити ocStore Документація Історія версій ocStore Блоги Модулі Шаблони Назад Безкоштовні шаблони Платні шаблони Де купувати модулі? Послуги FAQ OpenCart.Pro Назад Демо Купити Порівняння × Створити... Important Information На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність. Я даю згоду
magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 думаю кеш в таких случаях все решает Надіслати Поділитися на інших сайтах More sharing options...
chukcha Опубліковано: 16 серпня 2017 Автор Share Опубліковано: 16 серпня 2017 CREATE TABLE IF NOT EXISTS `oc_product_description` ( `product_id` int(11) NOT NULL, `language_id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `description` text NOT NULL, `meta_description` varchar(255) NOT NULL, `meta_keyword` varchar(255) NOT NULL, `seo_title` varchar(255) NOT NULL, `seo_h1` varchar(255) NOT NULL, `tag` text NOT NULL, `custom_title` varchar(255) DEFAULT '', PRIMARY KEY (`product_id`,`language_id`), KEY `name` (`name`), KEY `language_id` (`language_id`), FULLTEXT KEY `ft_namerel` (`name`,`description`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 10 минут назад, magecode сказал: да никуда, для fulltext'a просто оставляют таблицы в myisam. Да? Надіслати Поділитися на інших сайтах More sharing options... Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options... magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options... sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення SP Telegram повідомлення FREE Автор: spectre Відключити порожні категорії Автор: spectre SEO Автор тексту категорії / фільтра / блогу з датою оновлення контенту + мікророзмітка Автор: radaevich Промо банери в категоріях товарів Автор: IHOR1989 Trend - адаптивний універсальний шаблон Автор: DSV
Dotrox Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 3 часа назад, chukcha сказал: конвертируйте в InnoDb С каких пор это стало способом оптимизации? 3 часа назад, chukcha сказал: рука очень медленно потянулась влепить минус. Тянуться придётся долго, они всё ещё не работают 1 час назад, magecode сказал: для fulltext'a просто оставляют таблицы в myisam InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. Надіслати Поділитися на інших сайтах More sharing options...
magecode Опубліковано: 16 серпня 2017 Share Опубліковано: 16 серпня 2017 36 minutes ago, Dotrox said: InnoDB поддерживает полнотекстовые индексы где-то с одной из первых версий в ветке MySQL 5.6. да, но воспользоваться им мне так и не удалось. Хватило опыта в myisam. Надіслати Поділитися на інших сайтах More sharing options...
sitecreator Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 2 часа назад, Dotrox сказал: С каких пор это стало способом оптимизации? Есть мнение (здесь на форуме, например, высказывали), что InnoDb не хуже и не лучше MyIsam применительно к опенкарт в плане производительности. Если есть обратные выводы, то интересно было бы взглянуть на данные статистики в сравнении. Из косвенных недостатков. Это, конечно, не недостаток движка/типа таблицы. Некоторые дамперы создают дамп БД с таблицами InnoDb так, что не в состоянии потом воссоздать таблицы из этого дампа. Вот та же самая БД с MyIsam без проблем дампится и восстанавливается, а с InnoDb вылетают ошибки. Так, например, себя ведет Sypex Dumper с дефолтными настройками. Надіслати Поділитися на інших сайтах More sharing options... markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку Последние темы Последние дополнения Последние новости Вся активність Головна Разное Курилка Возмущения пост
markimax Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 Бездумно вставляя индексы можно запросто наступить на грабли тормозов Индексы должны быть продуманы Надіслати Поділитися на інших сайтах More sharing options... sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0 Перейти до списку тем Зараз на сторінці 0 користувачів Ні користувачів, які переглядиють цю сторінку
sv2109 Опубліковано: 17 серпня 2017 Share Опубліковано: 17 серпня 2017 мне кажется, что для опенкарта в innoDB нету никакого смысла. innoDB быстрее для записи, MyISAM - для чтения. innoDB в отличии от MyISAM при записи блокирует не всю таблицу, а только ту ее строку с которой работает, поэтому если нужно много писать в какую-то таблицу, то для нее лучше использовать innoDB она будет работать быстрее, но в магазине в основном происходит именно чтение, так как новый товар создали один раз и читают тысячи раз, а для чтения быстрее MyISAM, так как она проще. Поэтому я очень сомневаюсь, что для опенкарта innoDB будет быстрее. innoDB поддерживает транзакции, поэтому считается более надежной и используется на серьезных проектах, но опенкарт все равно транзакции не использует, innoDB поддерживает внешние ключи, которые в опенкарт тоже не используются innoDB лучше восстанавливается после сбоя - это наверное единственная причина, по которой стоило бы использовать этот движок, например для таблиц с данными о покупках, платежных операциях итд. Для всего остального есть бэкапы которые решают эту проблему, в том же Sypex Dumper упомянутом выше есть возможность делать бэкапы по крону, хоть через каждую минуту. поэтому и смысла использовать innoDB в опенкарт я не вижу. Скорости он не добавит, а преимущества этого движка опенкарт все равно особо не почувствует. Надіслати Поділитися на інших сайтах More sharing options... Створіть аккаунт або увійдіть для коментування Ви повинні бути користувачем, щоб залишити коментар Створити обліковий запис Зареєструйтеся для отримання облікового запису. Це просто! Зареєструвати аккаунт Вхід Уже зареєстровані? Увійдіть тут. Вхід зараз Share More sharing options... Передплатники 0
Recommended Posts