对于困难的描述感到抱歉,但我知道没有更好的方式来表达它。
当我通过phpMyAdmin网络界面查看MySQL数据库的某些表格时,前两列的数字以' 3'为前缀。
因此,如果第一列的编号为99,则phpMyAdmin显示3939。
第二列的编号为3592,phpMyAdmin的编号为33353932。
如果我使用mysql
CLI检查记录,它们会正确显示。
它只发生在某些数据库的某些表中的某些列中...而不是全部。
因此,它可能是表格本身或某些内容与phpMyAdmin。
系统/版本信息:
我希望有人知道这里可能会发生什么。
如果您想进一步澄清,请告诉我。
mysql CLI:
+------------------------------+
| Tables_in_gsb |
+------------------------------+
| gsb_challenge |
| gsb_challenge_pos |
| gsb_challenge_scope |
| gsb_copyright |
| gsb_correction |
| gsb_correction_gold |
| gsb_correction_literality |
| gsb_correction_sentalign |
| gsb_correction_tag |
| gsb_correction_tokenization |
| gsb_correction_wordalign |
| gsb_doc_counts |
| gsb_doc_status |
| gsb_doc_warnings |
| gsb_documents |
| gsb_log |
| gsb_reports_verbnet |
| gsb_semlex_entry |
| gsb_semlex_entry_cooc_cat |
| gsb_semlex_entry_cooc_lemma |
| gsb_semlex_entry_cooc_ne |
| gsb_semlex_entry_cooc_pos |
| gsb_semlex_entry_cooc_roles |
| gsb_semlex_entry_name |
| gsb_semlex_occurrence |
| gsb_status_flag |
| gsb_subcorpus |
| gsb_synsets |
| gsb_user |
| gsb_userCake_Groups |
| gsb_userCake_Users |
| gsb_v_accepted_docs |
| gsb_v_last_doc_status |
| gsb_v_last_doc_update |
| pmb_annotation_status |
| pmb_correction |
| pmb_correction_sentalign |
| pmb_correction_tag |
| pmb_correction_tokenization |
| pmb_dmatch |
| pmb_doc_counts |
| pmb_doc_lists |
| pmb_doc_status |
| pmb_doc_warnings |
| pmb_documents |
| pmb_lrec |
| pmb_lrec_dmatch |
| pmb_lrec_dmatch_backup |
| pmb_lrec_promatch |
| pmb_promatch |
| pmb_promatch_copy |
| pmb_reports_verbnet |
| pmb_semlex_entry |
| pmb_semlex_entry_cooc_cat |
| pmb_semlex_entry_cooc_lemma |
| pmb_semlex_entry_cooc_pos |
| pmb_semlex_entry_cooc_roles |
| pmb_semlex_entry_cooc_semtag |
| pmb_semlex_occurrence |
| pmb_status_flag |
| pmb_subcorpus |
| pmb_synsets |
| pmb_synsets_new |
| pmb_userCake_Groups |
| pmb_userCake_Users |
| pmb_v_phrase_search |
+------------------------------+
SELECT * FROM pmb_semlex_occurrence ORDER BY part DESC LIMIT 10;
+------+--------+-------+------+------+--------+------+----------------+------+----+-----------+---------+-----------+--------+--------+--------+----------+----------------------------------+
| part | doc_id | tokid | from | to | toknum | snum | cat | pos | ne | roles | wordnet | wordsense | semtag | lemma | token | token_lc | entry_id |
+------+--------+-------+------+------+--------+------+----------------+------+----+-----------+---------+-----------+--------+--------+--------+----------+----------------------------------+
| 99 | 3592 | 15056 | 2202 | 2203 | 453 | 15 | (N/PP)\(N/PP) | LQU | | [] | O | O | NIL | " | " | " | 594f1919d740100ed2f3e4cfd4100329 |
| 99 | 3592 | 15055 | 2201 | 2202 | 452 | 15 | (N/PP)\(N/PP) | . | | [] | O | O | NIL | . | . | . | 594f1919d740100ed2f3e4cfd4100329 |
的phpmyadmin:
这不是我的数据库,我只维护它运行的服务器,所以我不认为这是恶作剧......他们甚至会怎么做?
答案 0 :(得分:0)
通过这些列为BINARY
类型的附加信息,我能够找到两个描述此行为的错误报告:
第一个应该已经在phpMyAdmin 4.3中解决了,但我看到你正在使用4.5版。相关的第二个问题是针对4.7.1版报告的,并在4.7.3版中修复。
尝试升级到phpMyAdmin 4.7.3或更高版本(在撰写最新版本时是4.7.7)。