летящий красный шарф
Проблемы и решения MySQL в параллельных сценариях
2018-01-15 08:29 от flying red scarf, 4974 чтения, 13 комментариев,собирать, редактироватьсодержание
1. Предпосылки
2. Проблема медленных запросов из-за блокировок таблиц
3. Каковы риски изменения структуры таблицы онлайн?
4. Анализ проблемы взаимоблокировки
5. Анализ проблемы ожидания блокировки
6. Резюме
1. Предпосылки
Для систем баз данных улучшение параллелизма в условиях многопользовательского параллелизма и обеспечение согласованности данных всегда было целью, которую преследовали системы баз данных.Это необходимо для удовлетворения потребностей большого количества одновременных обращений и обеспечения безопасности данных при этом условии. Для достижения этой цели в большинстве баз данных реализованы механизмы блокировки и транзакций, и базы данных MySQL не являются исключением. Несмотря на это, в процессе развития бизнеса мы все равно будем сталкиваться с различными сложными проблемами, в этой статье мы продемонстрируем распространенные проблемы параллелизма и разберем решения в виде кейсов.
2. Проблема медленных запросов из-за блокировок таблиц
Во-первых, давайте рассмотрим простой случай, запросим информацию о пользователе на основе идентификатора:
mysql> select * from user where id=6;
Общее количество записей в этой таблице равно 3, но выполнение заняло 13 секунд.
Когда возникает эта проблема, наша первая мысль — посмотреть на текущий статус процесса MySQL:
Из процесса видно, что оператор select ожидает блокировку таблицы, так какой же запрос генерирует эту блокировку таблицы? Этот результат не показывает прямой связи, но мы можем предположить, что большая его часть генерируется оператором обновления (поскольку в процессе нет другого подозрительного SQL).Чтобы подтвердить наше предположение, сначала проверьте структуру пользовательской таблицы:
Конечно же, пользовательская таблица использует механизм хранения MyISAM, MyISAM создаст блокировку таблицы перед выполнением операции и автоматически разблокирует ее после завершения операции. Если операция является операцией записи, тип блокировки таблицы — блокировка записи, а если операция — операция чтения, тип блокировки таблицы — блокировка чтения. Как вы понимаете, блокировки записи будут блокировать другие операции (включая чтение и запись), что делает все операции последовательными, при блокировках чтения операции чтения-чтения можно распараллелить, но операции чтения-записи все равно будут последовательными. В следующем примере демонстрируется случай, когда блокировка таблицы (блокировка чтения), параллельное чтение-чтение и последовательное чтение-запись указаны явно.
Чтобы явно открывать/закрывать блокировки таблиц, используйте блокировку чтения/записи пользователем таблицы, разблокировку таблиц;
session1:
сеанс2:
Видно, что сессия 1 разрешает блокировки таблицы (блокировки чтения) для выполнения операций чтения, в то время как сессия 2 может выполнять операции чтения параллельно, но операции записи заблокированы. Затем см.:
session1:
session2:
Когда сессия1 разблокирована, сессия2 сразу же начинает выполнять операции записи, то есть последовательное чтение-запись.
Суммировать:
На этом этапе мы в основном проанализировали причину проблемы и резюмировали ее.Когда механизм хранения MyISAM выполняет операцию, будет сгенерирована блокировка таблицы, которая повлияет на операции других пользователей над таблицей.Если блокировка таблицы является блокировка записи заставит других пользователей оперировать строками.Если это блокировка чтения, операции чтения других пользователей могут быть распараллелены. Так что иногда у нас есть простой запрос, который занимает много времени, чтобы увидеть, так ли это.
Решение:
1) Старайтесь не использовать механизм хранения MyISAM.В MySQL 8.0 все таблицы механизма хранения MyISAM были удалены, и рекомендуется использовать механизм хранения InnoDB.
2) Если вы должны использовать механизм хранения MyISAM, уменьшите время записи;
3. Каковы риски изменения структуры таблицы онлайн?
Если однажды бизнес-системе потребуется увеличить длину поля, можно ли будет изменить его прямо в режиме онлайн? Прежде чем ответить на этот вопрос, давайте рассмотрим случай:
Приведенный выше оператор пытается изменить длину поля имени пользовательской таблицы, и этот оператор блокируется. По соглашению проверяем текущий процесс:
Из процесса видно, что оператор alter ожидает блокировки метаданных, и эта блокировка метаданных, вероятно, вызвана приведенным выше оператором select, что как раз и есть. При выполнении операций DML (выбрать, обновить, удалить, вставить) к таблице добавляется блокировка метаданных, которая гарантирует, что структура таблицы не будет изменена во время запроса, поэтому указанный выше оператор alter будет заблокирован. А что, если порядок выполнения будет обратным и сначала будет выполнен оператор alter, а затем оператор DML? Будут ли заблокированы операторы DML? Например, если я изменяю структуру таблицы в онлайн-среде, будет ли заблокирован онлайн-оператор DML? Ответ: не уверен.
В MySQL 5.6 была предоставлена функция интерактивного ddl, позволяющая выполнять некоторые операторы DDL и операторы DML одновременно. Онлайновый ddl был улучшен в текущей версии 5.7, что позволяет выполнять большинство операций DDL в режиме онлайн. Видеть:Dev.MySQL.com/doc/Furious/…
Таким образом, во время выполнения DDL для определенного сценария, будет ли заблокирован DML, зависит от сценария.
Резюме: Благодаря этому примеру у нас есть общее представление о блокировках метаданных и онлайн-ddl.Если нам нужно изменить структуру таблицы онлайн в процессе развития бизнеса, мы можем обратиться к следующим решениям:
1. Старайтесь делать это в период времени с небольшим объемом бизнеса;
2. Проверьте официальные документы и подтвердите, что изменение таблицы, которое должно быть выполнено, может выполняться одновременно с DML и не будет блокировать онлайн-бизнес;
3. Рекомендуется использовать инструмент pt-online-schema-change компании percona, который мощнее официального онлайн-ddl.Его основной принцип: сделать полную копию через оператор insert...select... и запишите структуру таблицы с помощью триггеров. Приращение, созданное в процессе изменения, для достижения цели изменения структуры таблицы.
Например, чтобы внести изменения в таблицу А, необходимо выполнить следующие основные шаги:
Создайте пустую структуру таблицы назначения таблицы, A_new;
Создание триггеров в таблице A, включая добавление, удаление и изменение триггеров;
Скопируйте данные в целевую таблицу по сегментам с помощью операторов insert...select...limit N
После завершения копирования переименуйте таблицу A_new в таблицу A.
4. Анализ проблемы взаимоблокировки
Тупик иногда возникает в онлайн-среде.Взаимоблокировка — это ситуация, в которой две или более транзакций ждут друг друга, чтобы снять блокировки, что приводит к транзакциям, которые никогда не могут быть завершены. Чтобы проанализировать проблему, мы смоделируем ниже простую тупиковую ситуацию, а затем обобщим некоторые идеи анализа.
Демонстрационная среда: MySQL5.7.20 Уровень изоляции транзакций: RR
Пользователь таблиц:
CREATE TABLE `user` ( |
---|
Ниже показано, как транзакция 1 и транзакция 2 работы:
Транзакция 1 | Транзакция 2 | Мониторинг транзакций | |
---|---|---|---|
T1 |
begin; Query OK, 0 rows affected (0.00 sec) |
begin; Query OK, 0 rows affected (0.00 sec) |
|
T2 |
select * from user where id=3 for update; +----+------+------+ |
select * from user where id=4 for update; +----+------+------+ |
выберите * из information_schema.INNODB_TRX; Запрашивая таблицу транзакций innodb метабазы данных, отслеживается, что количество текущих транзакций равно 2, то есть транзакция 1 и транзакция 2. |
T3 |
update user set name='haha' where id=4; Поскольку запись с id=4 была заблокирована транзакцией 2, инструкция будет заблокирована. |
Для мониторинга текущего количества транзакций работает 2. | |
T4 | состояние блокировки |
update user set name='hehe' where id=3; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction Запись с идентификатором = 3 была заблокирована транзакцией 1, и транзакция удерживает блокировку строки для записи с идентификатором = 4. В это время механизм хранения InnoDB обнаруживает взаимоблокировку, и транзакция откатывается. |
Транзакция 2 откатывается, транзакция 1 все еще выполняется, а число отслеживаемых в данный момент транзакций равно 1. |
T5 |
Query OK, 1 row affected (20.91 sec)Rows matched: 1 Changed: 1 Warnings: 0 Поскольку транзакция 2 откатывается, возобновляется исходный блокирующий оператор обновления. |
Количество отслеживаемых в данный момент транзакций равно 1. | |
T6 |
совершить; Query OK, 0 rows affected (0.00 sec) |
Транзакция 1 была совершена, транзакция 2 откатывалась назад, а количество текущих операций выполнения составляет 0. |
Это простой сценарий взаимоблокировки. Транзакция 1 и транзакция 2 ждут друг друга, чтобы снять блокировку. Механизм хранения InnoDB обнаруживает взаимоблокировку и откатывает транзакцию 2, что заставляет транзакцию 1 больше не ждать блокировки транзакции B и может продолжить. Так как же механизм хранения InnoDB обнаруживает взаимоблокировки? Чтобы понять эту проблему, мы сначала проверим состояние InnoDB в это время:
show engine innodb status\G
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-01-14 12:17:13 0x70000f1cc000
*** (1) TRANSACTION:
TRANSACTION 5120, ACTIVE 17 sec starting index read
mysql tables in use 1, locked
1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 10, OS thread handle 123145556967424, query id 2764 localhost root updating
update user set name='haha' where id=4
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5120 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004;
asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;
*** (2) TRANSACTION:
TRANSACTION 5121, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 11, OS thread handle 123145555853312, query id 2765 localhost root
updating
update user set name='hehe' where id=3
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL
RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact
format; info bits 0
0: len 4; hex 80000003; asc ;;
1: len 6; hex 0000000013fe; asc ;;
2: len 7; hex 5500000156012f; asc U V /;;
3: len 4; hex 68656865; asc hehe;;
4: len 4; hex 80000014; asc ;;
*** WE ROLL BACK TRANSACTION (2)
Есть много индикаторов состояния InnoDB.Здесь мы перехватываем информацию, связанную с взаимоблокировками.Видно, что InnoDB может выводить самую последнюю информацию о взаимоблокировках.На самом деле многие инструменты мониторинга взаимоблокировок также разработаны на основе этой функции.
В информации о взаимоблокировке отображается соответствующая информация о двух транзакциях, ожидающих блокировки (синий цвет представляет транзакцию 1, зеленый цвет представляет транзакцию 2), с акцентом на: ОЖИДАНИЕ ПРЕДОСТАВЛЕНИЯ ЭТОЙ БЛОКИРОВКИ и УДЕРЖИВАНИЕ БЛОКИРОВКИ.
WAITING FOR THIS LOCK TO BE GRANTED указывает информацию о блокировке, которую ожидает текущая транзакция.Из вывода видно, что транзакция 1 ожидает блокировки строки с кучей № 5, а транзакция 2 ожидает блокировки строки с кучей № 7;
HOLDS THE LOCK(S): Указывает информацию о блокировке, удерживаемую текущей транзакцией.Из вывода видно, что транзакция 2 содержит кучу блокировок не из 5 строк.
Из вывода можно увидеть, что InnoDB прокатал обратно транзакцию 2 в конце.
Так как же InnoDB проверяет взаимоблокировки?
Самый простой способ, о котором мы думаем, это то, что если транзакция ожидает блокировки, если время ожидания превышает установленный порог, то операция транзакции завершается ошибкой, что позволяет избежать ситуации, когда несколько транзакций долго ждут друг друга. Параметр innodb_lock_wait_timeout используется для установки времени ожидания блокировки.
Если вы будете следовать этому методу, для решения тупиковой ситуации потребуется время (то есть ожидание, превышающее пороговое значение, установленное innodb_lock_wait_timeout), этот метод немного пассивен и влияет на производительность системы, механизм хранения InnoDB предоставляет лучший алгоритм для решения тупиковой ситуации. проблема, подождите алгоритм графа. Проще говоря, когда несколько транзакций начинают ждать друг друга, включается алгоритм графа ожидания, который откатывает одну из транзакций сразу после того, как алгоритм определяет, что взаимоблокировка заблокирована. Преимущество этого метода в том, что проверка является более активной, а время ожидания короче.
Ниже приведен основной принцип алгоритма графа ожидания:
Для простоты понимания давайте подумаем о тупике как о сценарии, в котором 4 машины блокируют друг друга:
4 машины рассматриваются как 4 транзакции, каждая из которых ожидает блокировки друг друга, что приводит к взаимоблокировке. Принцип алгоритма графа ожидания заключается в использовании транзакций в качестве узлов, а отношение ожидания блокировки между транзакциями представлено направленными ребрами.Например, когда транзакция A ожидает блокировки транзакции B, направленное ребро рисуется из узла A к узлу B, так что если ориентированный граф, состоящий из A, B, C и D, образует цикл, он оценивается как тупик. Это основной принцип алгоритма ожидания графа.
Суммировать:
1. Как проверить, нет ли тупика в развитии нашего бизнеса? Было введено, что, отслеживая состояние InnoDB, вы можете сделать небольшой инструмент для сбора записей взаимоблокировок для последующего просмотра.
2. Если возникает тупик, как должна реагировать бизнес-система? Из вышеприведенного мы видим, что когда InnoDB обнаруживает взаимоблокировку, она сообщает об обнаружении взаимоблокировки при попытке получить блокировку; попробуйте перезапустить информацию о транзакции для клиента и откатить транзакцию.Приложению необходимо перезапустить транзакцию на основе этой информации. .и сохраните локальный журнал для дальнейшего анализа, чтобы избежать возникновения следующей взаимоблокировки.
5. Анализ проблемы ожидания блокировки
В развитии бизнеса вероятность взаимоблокировки мала, но вероятность ожидания блокировки высока, потому что одна транзакция занимает ресурсы блокировки в течение длительного времени, в то время как другие транзакции продолжают ждать, пока предыдущая транзакция освободит блокировку.
Транзакция 1 | Транзакция 2 | Мониторинг транзакций | |
---|---|---|---|
T1 |
begin; Query OK, 0 rows affected (0.00 sec) |
begin; Query OK, 0 rows affected (0.00 sec) |
|
T2 |
select * from user where id=3 for update; +----+------+------+ |
Другие операции запроса |
выберите * из information_schema.INNODB_TRX; Запрашивая таблицу транзакций innodb метабазы данных, отслеживается, что количество текущих транзакций равно 2, то есть транзакция 1 и транзакция 2. |
T3 | Другие операции запроса |
update user set name='hehe' where id=3; Поскольку запись с id=3 заблокирована транзакцией 1, инструкция будет заблокирована (т.е. ожидание блокировки) |
Количество текущих транзакций отслеживается до 2. |
T4 | Другие операции запроса |
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction Время ожидания блокировки превышает пороговое значение, и операция завершается ошибкой. Примечание. В этот момент транзакция 2 не откатывается. |
Количество текущих транзакций отслеживается до 2. |
T5 | commit; | Транзакция 1 была зафиксирована, но транзакция 2 не была зафиксирована, и количество текущих транзакций равно 1. |
Из вышеизложенного видно, что транзакция 1 длительное время удерживает блокировку строки с id=3, а транзакция 2 генерирует ожидание блокировки, после того как время ожидания превышает innodb_lock_wait_timeout, операция прерывается, но откат транзакции не происходит. Если мы столкнемся с ожиданием блокировки в развитии бизнеса, это не только повлияет на производительность, но и вызовет трудности для вашего бизнес-процесса, потому что ваша бизнес-сторона должна адаптировать логику к ситуации ожидания блокировки, будь то повторная попытка операции или откат транзакции.
Информация о транзакциях и ожидании блокировки собирается в таблице метаданных MySQL, такой как INNODB_LOCKS, INNODB_TRX и INNODB_LOCK_WAITS в базе данных information_schema.Вы можете наблюдать ситуацию ожидания блокировки вашей бизнес-системы через эти таблицы. Вы также можете легко запросить взаимосвязь между транзакциями и ожиданием блокировки с помощью следующего оператора:
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query wating_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id; |
---|
результат:
waiting_trx_id: 5132
waiting_thread: 11
wating_query: update user set name='hehe' where id=3
blocking_trx_id: 5133
blocking_thread: 10
blocking_query: NULL
Суммировать:
1, пожалуйста, подождите блокировки мониторинга ваших бизнес-систем, что поможет вам понять текущие блокировки базы данных, а также поможет вам оптимизировать бизнес-процедуры;
2. В бизнес-системе должны быть сделаны соответствующие логические выводы для тайм-аута ожидания блокировки.
6. Резюме
Эта статья знакомит с несколькими проблемами параллелизма MySQL, которые мы обычно используем, на нескольких простых примерах и пытаемся придумать наши идеи по устранению этих проблем. В статье рассматриваются транзакции, блокировки таблиц, блокировки метаданных и блокировки строк, но проблемы параллелизма гораздо шире, чем перечисленные, например уровни изоляции транзакций, блокировки GAP и т. д. Реальных проблем параллелизма может быть много и они могут быть сложными, но идеи и методы устранения неполадок можно использовать повторно. проблема включает в себя репликацию, также необходимо поддерживать мониторинг ведущий/ведомый.
Использованная литература:
Цзян Чэнъяо "Механизм хранения InnoDB"
Ли Хунчжэ Ян Тинг "Руководство по устранению неполадок MySQL"
Хэ Сюньhedengcheng.com
Я рекламировал ===============================================
Meituan Dianping набирает Java-инженеров старших классов средней школы в Чэнду, Пекине и Шанхае с ежемесячной зарплатой 20-50 тыс. Если вам нужны внутренние рекомендации, вы можете написать мне: 360841519@qq.com
|
Эта статья основана наАтрибуция 2.5 Лицензионное соглашение с материковым КитаемПубликация, приветствуется перепечатка, вывод или использование в коммерческих целях, но необходимо сохранить авторство этой статьи.Ли Пинг(включая ссылки), конкретный метод работы можно найти здесь. Если у вас есть какие-либо вопросы или переговоры относительно авторизации, пожалуйста,Оставьте мне сообщение. |
- Классификация:MySQL
- Этикетка:MySQL, Замок, параллелизм
-
#1-й этаж Прогулка бога-вола 3 2018-01-15 09:18
хороший текстПоддержка(2)против (0) http://pic.cnblogs.com/face/348819/20130218153953.png -
#2-й этаж FaceSun 2018-01-15 13:49
неплохоПоддержка(0)против (0) -
#3-й этаж домино 2018-01-15 19:38
очень полезно, спасибоПоддержка(0)против (0) http://pic.cnblogs.com/face/u17196.jpg?id=29012616 -
#4-й этаж CowryLee 2018-01-16 10:47
Почему до сих пор люди используют таблицы myisam в продакшене?Поддержка(0)против (0) -
#5-й этаж Ганс 2018-01-16 11:13
отличныйПоддержка(0)против (0) http://pic.cnblogs.com/face/859549/20170630173301.png -
#6 этаж вырезка 2018-01-16 14:07
служба поддержкиПоддержка(0)против (0) http://pic.cnblogs.com/face/u41249.jpg -
#7 этаж alin_qu 2018-01-16 16:47
InnoDB, если обновленное поле не проиндексировано, кажется, что таблицу нужно заблокировать.Поддержка(0)против (0) -
№8 Этажарендодатель] летящий красный шарф 2018-01-16 16:51
@ alin_qu
даПоддержка(0)против (0) http://pic.cnblogs.com/face/352511/20150610133629.png -
№9 Этаж большой камень 2018-01-17 09:28
Оптимизация через sql - это бесконечное средство!
Может ли арендодатель поделиться некоторыми решениями по настройке MySql и индикаторами производительности тестирования?
Например, примерная таблица MySql, установленная по умолчанию, может выполнять w1 операций вставки в секунду или выполнять r1 запросов в секунду. После оптимизации ххх получаются вставки w2 или запросы r2. Это более интуитивно понятно.Поддержка(0)против (0) http://pic.cnblogs.com/face/u19592.jpg?id=28155008 -
№10 этаж Daniel Cai 2018-01-17 11:28
@ CowryLee
Это нормально использовать myisam в продакшене, для других не проблема больше проверять и меньше писать.Поддержка(0)против (0) http://pic.cnblogs.com/face/45820/20161103205209.png -
# 11 этаж Мастер Сяочэнь 2018-01-17 14:57
хороший текстПоддержка(0)против (0) http://pic.cnblogs.com/face/668104/20180314222145.png -
#12F ~Дождь идет грустный~ 2018-01-17 16:24
не могу читатьПоддержка(0)против (0) http://pic.cnblogs.com/face/856389/20171120165836.png -
№13 Этаж38927512018/1/18 14:54:59 owen zeng 2018-01-18 14:54
Очень хорошая учеба,Поддержка(0)против (0) http://pic.cnblogs.com/face/603809/20180102114138.png
[Событие] Конференция 2050 — Встреча программистов Blog Park (5.25 Ханчжоу, город Юньци)
[Рекомендуется] 0 юаней для бесплатного использования сервисов HUAWEI CLOUD
【Событие】Специальная покупка нового облачного сервера Tencent, скидка 50% на облаке
· Телефон Meizu Android Go прошел сертификацию FCC и стоит менее 600 юаней.
· Один удар десять, анализ робота AGV логистики Suning
· Интерпретация: сколько стоит Xiaomi?
· Новый Surface Pro LTE официально представлен вместе с новыми конфигурациями Surface Pro.
· День 2 F8: новые возможности для социальных сетей и дизайна с помощью виртуальной реальности
» больше новостей...
· Как стать хорошим программистом?
· Надзорная дорога инженеров Rookie - от кампуса на рабочее место
· Как определить технические способности и уровень людей?
· Руководство для начинающих для самостоятельных студентов
· влюбиться в программиста
» Другие статьи базы знаний...
About
|
Ли Пинг, в настоящее время занимается дизайном и разработкой в интернет-компании O2O. В свободное время он любит бегать, читать и играть в игры. Нравится простая и эффективная рабочая среда, знакомые JavaEE, SOA, архитектура баз данных, оптимизация, эксплуатация и обслуживание системы, большие порталы, опыт построения финансовых систем. RHCE, ОСР MySQL. Участники проекта с открытым исходным кодом MyCAT. |
Возраст сада:6 лет 5 месяцев
честь:Рекомендуемый блог
вентилятор:846
обрати внимание на:0 +Добавить подписку
последний комментарий
- Re:Анализ и проектирование товарной модели в системе электронной коммерции
(Последняя статья собиралась опубликовать вчера, но новый зарегистрированный пользователь в тот день не оставил комментария.) После сна я встал и подумал об этом. На самом деле таблица спецификаций тоже должна быть привязана к категории, а правила привязки такие же, как и атрибуты. Иначе, если я войду в айфон, то как там могут быть Пакет 1, Пакет 2, и разница между лицензионной версией и гонконгской версией в спецификациях? Ведь было бы странно выбирать платье, чтобы показать это. --function0917 - Re:Анализ и проектирование товарной модели в системе электронной коммерции
#Вопросы о привязке между таблицей классификации и таблицей атрибутов, узнайте о # ------------------------------------------------------------ Таблица классификации продуктов имеет бесконечную классификацию, а таблица атрибутов продуктов должна быть плоской. Возьмем обувь в качестве примера: в таблице классификации есть обувь (cid=1) -> высокие каблуки (cid=1001), а в таблице атрибутов размер, цвет и цена обуви (это благодаря напоминание, иначе бы я его не заметил) , то вот в чем проблема. Должен ли идентификатор классификации (поле — cid) в моей таблице атрибутов продукта быть cid обуви или высоких каблуков. ------------------------------------------------------------ Прочитав книгу сто раз, я вижу это для себя.В процессе набора текста я вдруг подумал о решении - "просто высокие".Как следует из названия, если и туфли, и высокие каблуки могут иметь такие атрибуты, как цвет и размер , тогда будет привязан cid более высокого уровня. Таким образом, характеристики, которые могут быть у туфель на высоких каблуках в будущем = их собственные особые характеристики (как правило, высокая + относительно высокая + ненависть к небу низкой + я действительно не могу придумать больше туфель на высоком каблуке..) + характеристики всех родительских категорий (сколько бы родителей ни было, все приносят сюда.) -------------------------------------------- Что блогеры думают по этому поводу? --function0917 - Re: Глубокое понимание JVM (7) - инструмент мониторинга производительности
отметка -- Рыбка 2017 - Re: Глубокое понимание JVM (1) - основные принципы
Здравствуйте, вы можете перепечатать эту вашу статью? Будет указан оригинальный автор и оригинальная ссылка. Спасибо~ -- Инженер - Застрял - Re: Глубокое понимание JVM (4) - алгоритм сборки мусора
Могу я спросить, что такое достижимые и недостижимые объекты? --Главное
Файл эссе
- Январь 2018 (2)
- Октябрь 2017 (1)
- Сентябрь 2017 (4)
- август 2017 (7)
- июнь 2015 г. (1)
- январь 2015 г. (2)
- октябрь 2014 г. (2)
- сентябрь 2014 г. (2)
- Май 2014 (1)
- март 2014 г. (2)
- январь 2014 г. (1)
- сентябрь 2013 г. (1)
- Август 2013 года (2)
- май 2013 г. (1)
- Апрель 2013 г. (1)
- март 2013 г. (1)
- декабрь 2012 г. (1)
- ноябрь 2012 г. (1)
- сентябрь 2012 г. (1)
- июнь 2012 г. (2)
- май 2012 г. (4)
- март 2012 г. (1)
календарь
|
||||||
день | один | два | три | Четыре | пять | шесть |
---|---|---|---|---|---|---|
29 | 30 | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
мой ярлык
- Maven(3)
- Jenkins(2)
- Nexus(2)
- Sonar(2)
- Svn(2)
- Tomcat(2)
- параллелизм(1)
- Параллелизм оптимистичная блокировка пессимистичная блокировка(1)
- большой сайт(1)
- Код качества CheckStyle PMD JDEpend Eclemma Metric(1)
- Более
классификация эссе
- Apache Mina(1)
- Eclipse(1)
- Hibernate(2)
- Java(19)
- JVM(8)
- MongoDB(2)
- MySQL(4)
- RCP/SWT/Jface(1)
- SOA(1)
- Spring(3)
- Непрерывная интеграция (4)
- Большой сайт(3)
- многопоточный(1)
- Проекты с открытым исходным кодом (2)
- ловкость (1)
- Другое(7)
- Шаблоны проектирования(1)
- Структура данных/алгоритм(1)
- Архитектура системы(3)
- платить(1)
- рефакторинг(1)
Рекомендуемая таблица лидеров
- 1. Эволюция крупномасштабной архитектуры системы веб-сайтов (211)
- 2. Душа большого сайта - перформанс (63)
- 3. Анализ и проектирование товарной модели в системе электронной коммерции — продолжение (51)
- 4. Анализ и проектирование товарной модели в системе электронной коммерции(47)
- 5. Создал два инструмента для мониторинга баз данных и в ближайшем будущем планирует открыть их исходный код (39)
Читать таблицу лидеров
- 1. Эволюция системной архитектуры крупномасштабных веб-сайтов (48975)
- Анализ и проектирование бизнес-моделированной модели 2. Система (15338)
- 3. Душа большого сайта - перформанс (15165)
- 4. Используйте Maven+Nexus+Jenkins+Svn+Tomcat+Sonar для создания среды непрерывной интеграции (1) (14527)
- 5. Глубокое понимание JVM (1) — основные принципы (14068)
Copyright © 2018 Летающий красный шарф